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.
At 12:48 PM 4/23/2007, Gene LeDuc wrote:
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, [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
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
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
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
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
