ruz at bestpractical
Apr 10, 2012, 9:34 AM
Post #5 of 5
(215 views)
Permalink
|
On Tue, Apr 10, 2012 at 20:17, Paul Tomblin <ptomblin [at] xcski> wrote:
> On Tue, Apr 10, 2012 at 12:12 PM, Ruslan Zakirov <ruz [at] bestpractical>
> wrote:
>>
>> >> # Find the custom field "myCustom"
>> >> my $myCustom = $ticket->FirstCustomFieldValue("myCustom");
>> >> $RT::Logger->debug("custom field = ". $myCustom);
>> >>
>> >> but it never gets the value. Is there somewhere else I need to look
>> >> for
>> >> that custom field? Is it in the TransactionObj instead? Am I going to
>> >> have
>> >> to use TransactionBatch for this?
>> >>
>> > If anybody cares about this, yes, I had to use TransactionBatch.
>>
>> Status is set before custom field. Transaction batch delays scrip
>> execution to the point where both changes are seen on the ticket.
>
>
> What surprised me about this is that I didn't have to change the
> RT::Condition or the RT::Action subclasses I used, I only had to enable
> TransactionBatch in the config, and in initialdata (for this testing phase,
> I clean the database and do another make initdb each time) add "Stage =>
> 'TransactionBatch'" to the @Scrips definition.
Yes, switch to batch stage is transparent in most cases. Scrips that
work in TransactionCreate stage in most cases work in batch stage
without any changes, but reverse switch may be harder or impossible as
batch stage provides additional ways to get information about the
situation.
> --
> http://www.linkedin.com/in/paultomblin
> http://careers.stackoverflow.com/ptomblin
>
--
Best regards, Ruslan.
|
