[rt-users] Order of transactions

[Gene LeDuc]

That's what I've decided to do.  The workflow will be bouncing around like 
a pinball, though, as scrips and templates change fields and queues.  I'm 
also thinking about fooling around with TransactionBatch to see if it might 
help in this instance.  I'm using RT 3.6.3.

Thanks,
Gene

At 04:36 PM 4/5/2007, Kenneth Crocker wrote:
>Gene,
>
>
>
>         We had trouble with some code in a template and found out we were 
> trying to do too much with one return process (ie. trying to get more 
> than 1 piece of information). We use RT 3.4.5. What we did was break up 
> the code (in the template) to gather and return 1 piece of info at a time 
> in a top down design and it worked. Maybe it will for you as well.
>
>Kenn
>LBNL
>
>Gene LeDuc wrote:
>>Hi Kenn,
>>At 12:35 PM 4/4/2007, you wrote:
>>>         Why don't you put some code in the IP E_mail template to grab 
>>> the transaction value?
>>I do check for the IP value in the e-mail, but that only determines which 
>>version of the message gets sent (either kill the port or call me to 
>>discuss the issue).  So a missing IP value is legal, as is an existing IP 
>>value.  The "State" value is used to move tickets between queues, 
>>determine which e-mail to send in each queue, and what the ticket status 
>>should be at various points in the life of the ticket.
>>What should be happening is this:
>>1.  RT user logs in, puts a value into IP, changes State from "Info" to 
>>"Kill", then clicks "Save Changes"
>>1a.  RT changes IP and State fields
>>2.  State-change to "Kill" triggers scrip that moves ticket into TNS queue
>>3.  Queue-change from "DMCA" to "TNS" with "State" set to "Kill" triggers 
>>scrip that sends a request to kill the port associated with the IP.
>>What is actually happening is this:
>>1.  RT user logs in, puts a value into IP, changes State from "Info" to 
>>"Kill", then clicks "Save Changes"
>>1a.  RT changes State field (but not IP field)
>>2.  State-change to "Kill" triggers scrip that moves ticket into TNS queue
>>3.  Queue-change from "DMCA" to "TNS" with "State" set to "Kill" triggers 
>>scrip that sends a request to call me to discuss the issue (since there's 
>>no IP field at this point)
>>3a.  RT changes IP field
>>So the user changes 2 fields in step 1 and hits "Save Changes", but the 
>>State field triggers steps 2 and 3 before the IP field (which step 3 
>>needs) is changed.
>>I tried putting the template to sleep for 5 seconds before grabbing the 
>>IP value for the e-mail, in the hope that the IP field would have been 
>>changed by the time it wakes up.  But nooooo.  It appears that the entire 
>>execution chain (2 scrips and a template) that is triggered by the State 
>>change has to complete before RT tries setting the IP field.
>>What I'd like to do is coax RT into consistently making the IP change 
>>before the State change triggers the scrip, then it would work.
>>
>>>Gene LeDuc wrote:
>>>>Hi All,
>>>>I saw a post with a similar issue a while ago, but the solutions 
>>>>offered don't fit my situation.
>>>>I have 2 custom fields, IP and State.  IP is a single value text field 
>>>>and State is a single value combo box.
>>>>I'm modifying both values using the Basics tab of the Ticket screen.
>>>>I set IP to some value and State to some value via the pulldown menu, 
>>>>then click "Save Changes".
>>>>My expectation is that both values would be modified before any scrips 
>>>>are triggered.
>>>>However...  It appears that RT modifies State first, which fires a 
>>>>custom-condition "State Change" scrip.  IP then gets modified only 
>>>>after the scrip fires, so it is not available to a template used by the 
>>>>"State Change" scrip.  The problem is that I need the IP in order to 
>>>>send out an e-mail that makes sense.
>>>>The History display shows the State being changed, then the actions of 
>>>>the "State Change" scrip (a queue change and the e-mail), then the IP 
>>>>value being set.
>>>>Is there a way I can hold off on the "State Change" scrip until after 
>>>>both values have been changed in the Basics screen?
>>>>It's not a "scrip execution order" issue, because there's only 1 scrip 
>>>>involved.  The issue is that I need all of the updates from the web 
>>>>page to happen before any scrips are triggered.
>>>>I can work around this if I make the changes in 2 steps (change IP then 
>>>>change State), but I'm sure my users won't see the logic in doing this.
>>>>I thought about adding a condition to the "State Change" scrip that 
>>>>makes sure that IP is not null.  That would keep the e-mail from going 
>>>>out with a null IP, but then the scrip condition would not be satisfied 
>>>>when the IP value does finally gets modified.
>>>>Has anyone else conquered this issue?  Or am I missing something pretty 
>>>>basic?
>>>>Thanks,
>>>>Gene
>>>
>>>
>>>--
>>>Gene LeDuc, GSEC
>>>Security Analyst
>>>San Diego State University
>
>
>--
>Gene LeDuc, GSEC
>Security Analyst
>San Diego State University