<html>
<body>
This behavior doesn't seem to apply to all fields. I've gotten it
to revert when my scrip modifies Owner and a custom field, but if I
modify Priority it doesn't get undone. I've sent it to
rt-bugs.<br><br>
At 12:48 PM 4/23/2007, Gene LeDuc wrote:<br>
<blockquote type=cite class=cite cite="">I think I know what is
happening. At least this is what's happening to me.<br><br>
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.<br><br>
That description is kind of convoluted, so I'll give an example that I
hope is clearer.<br><br>
1. I have a ticket whose Owner is Nobody and Status is Open.<br>
2. I also have an OnResolve scrip that changes the Owner to the
logged-in user if it is Nobody.<br>
3. Using the webui I change the Status to Resolved (but leave the
Owner set to Nobody).<br>
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.<br><br>
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.<br><br>
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.<br><br>
You might be able to use TransactionBatch to work around this interesting
but irritating feature.<br><br>
<br>
At 08:19 AM 4/23/2007, Silvana.Giberti@esa.int wrote:<br><br>
<blockquote type=cite class=cite cite=""><font size=2>I'm still having
problems with scrips modifying some custom field values.</font> <br><br>
<font size=2>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.</font>
<br><br>
<font size=2>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.</font> <br><br>
<font size=2>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.</font>
<br>
<br>
<font size=2>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.</font> <br><br>
<font size=2>All custom fields are defined global for tickets in all
queues.</font> <br><br>
<font size=2>Does anyone have an idea of what to do to fix this
problem?</font> <br><br>
<font size=2>Thanks,</font> <br>
<font size=2>Silvana</font> <br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" eudora="autourl">
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
Community help:
<a href="http://wiki.bestpractical.com/" eudora="autourl">
http://wiki.bestpractical.com</a><br>
Commercial support: sales@bestpractical.com<br><br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
<br>
Buy a copy at
<a href="http://rtbook.bestpractical.com/" eudora="autourl">
http://rtbook.bestpractical.com</a> </blockquote><br><br>
-- <br>
Gene LeDuc, GSEC<br>
Security Analyst<br>
San Diego State University <br>
_______________________________________________<br>
<a href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users" eudora="autourl">
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</a><br>
<br>
Community help:
<a href="http://wiki.bestpractical.com/" eudora="autourl">
http://wiki.bestpractical.com</a><br>
Commercial support: sales@bestpractical.com<br><br>
<br>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
<br>
Buy a copy at
<a href="http://rtbook.bestpractical.com/" eudora="autourl">
http://rtbook.bestpractical.com</a> </blockquote>
<x-sigsep><p></x-sigsep>
<br>
-- <br>
Gene LeDuc, GSEC<br>
Security Analyst<br>
San Diego State University</body>
</html>