Scrips and Custom fields values

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

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.

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.

Hi Silvana

You might want to make a local overlay of Scrips where you change
lib/RT/Scrips_Overlay.pm’s _FindScrips method to dump out which scrips
were found, rather than just a count of the applicable scrips. Once
you have
the id, tracking down which scrip is misbehaving would be a lot easier.

-kevin

Hi Silvana,

I’ve had odd results too with Custom Fields on ticket creation & with
custom Scrips. Two things I’ve found which have helped.

  1. Turning on Batch mode in RT_SiteConfig.pm alleviates some of the
    problems of not knowing which scrip will trigger first.

    Enable Batching of Transactions *** Custom ***

    Set($UseTransactionBatch, 1);

  2. Applying changes to Custom Fields in custom Templates for that
    queue. I found that I always knew for example that a Correspondence
    template would be used when someone replied to a ticket. Plus a
    Template with a Queue overrides the global Template, so I’ve been able
    to incorporate some code into those autogenerated & reply templates to
    look for certain things. This has worked pretty good with the
    StockAnswers add-on, a specific selection of common reply text will
    through the Template set a Custom Field when the Email goes out.

Looking at your question I suspect the Batch mode might help in the
diagnosis of the order in which things run, under Stage: there should be
a new option once you restart called TransactionBatch.

Hope that works itself out.

  • Scott

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@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


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@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

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, Silvana.Giberti@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


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@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


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@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

Thanks everybody for helping me on this issue!

I was finally able to solve my problem on scrips and custom fields values.
As few people had suggested, I just had to enable the batch transaction
stage in the RT_SiteConfig.pm, setting stage “TransactionBatch” for that
one scrip that updates the CF, restart httpd, and magically everything
worked well!
Now I can see that all other transactions are executed and committed
before, and then the batch transaction starts and completes successfully.
You just have to re-display the page to see the changes.

I agree with that the problem may be generated by the webui that runs an
extra transaction and the CF update gets undone.

Anyway, that was a great input, thanks again!

  • Silvana