[rt-users] Scrips and Custom fields values

[Gene LeDuc]

I think I know what is happening.  At least this is what's happening to me.

When you click the submit button after changing a field in a ticket using 
the webui, it seems to run a transaction that compares the displayed field 
values after all of the other transactions have run - and then it reset 
them to what it thinks they should be.  And since it doesn't seem to know 
that a scrip modified a field, it sets it back to what it was when the 
Submit was clicked.

That description is kind of convoluted, so I'll give an example that I hope 
is clearer.

1.  I have a ticket whose Owner is Nobody and Status is Open.
2.  I also have an OnResolve scrip that changes the Owner to the logged-in 
user if it is Nobody.
3.  Using the webui I change the Status to Resolved (but leave the Owner 
set to Nobody).
4.  My OnResolve srcip fires and changes the Owner to the logged-in 
user.  But then it seems that the webui compares all of the values of the 
ticket's fields against what it knows about (it apparently doesn't know 
about the owner change) and sees that the ticket Owner is not Nobody.  But 
since it was Nobody when I hit the Submit button, it changes it back to 
that value.  And that's the final word, because no transaction run after it 
does this (I tried testing for owner change to nobody, but it never fired), 
so I can't undo the unwanted change.

If I resolve my tickets via e-mail, everything is fine.  But using the 
webui runs that extra last transaction and my scrip action gets undone.  I 
finally realized what was happening when I noticed that there were 2 
bullets listed under "Results" on my ticket when it redisplayed the 
ticket.  The first showed the status change that I made and the second 
showed the owner being set back to Nobody.

If you have a custom field displayed and you are changing it with a scrip 
that is triggered by an action caused by a webui change, the webui is 
probably changing it back to what it thinks it's supposed to be.

You might be able to use TransactionBatch to work around this interesting 
but irritating feature.


At 08:19 AM 4/23/2007, Silvana.Giberti at esa.int wrote:

>I'm still having problems with scrips modifying some custom field values.
>
>I have 2 custom fields created at ticket creation time, and 2 others to be 
>updated whenever one of the other two change value. This is done by 
>several scrips, 2 running at ticket creation and the others running when 
>one of the 2 initial custom field is updated.
>
>Sometimes it happens that one of the other 2 custom fields is updated 
>twice by the third scrip, a first time with the right value, and a second 
>time instead with the value the custom field had before, with the final 
>effect that the value never changes.
>
>I've been trying many different changes, and also to recreate the cf and 
>the scrips into a different installation of RT, with the only effect that 
>the behaviour is the opposite: if with the first installation the third 
>custom field is always right and the fourth one never changes, with the 
>second installation the situation is the opposite, that is, the third 
>never changes and the fourth is ok.
>
>Comparing the 2 cases in RT log file, it looks like there's an extra 
>transaction firing after the update of the wrong custom field, but I can't 
>tell what it does.
>
>All custom fields are defined global for tickets in all queues.
>
>Does anyone have an idea of what to do to fix this problem?
>
>Thanks,
>Silvana
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Community help: http://wiki.bestpractical.com
>Commercial support: sales at bestpractical.com
>
>
>Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
>Buy a copy at http://rtbook.bestpractical.com


-- 
Gene LeDuc, GSEC
Security Analyst
San Diego State University 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20070423/f4f33507/attachment.htm>