[rt-users] Notifications are sent before status and custom field changes are applied?

[Craig Ringer]

Hi all

I was recently surprised to see that when a ticket is updated via the
web ui, notifications appear to be sent to ticket/queue watchers before
any custom field changes are applied. Tested in 4.0.13, albeit with a DB
that was created originally on 4.0.7.

After reading the code in question, it looks like the message is
recorded against the ticket before any other field changes, and all the
default notification scripts run on TransactionCreate not on
TransactionBatch, so they fire their notifications immediately.

Do any of the other RT users here know of a reason *not* to use
TransactionBatch for sending email notifications?

Have any of the other RT users here had similar issues?


The behaviour surprising for a couple of reasons:

* RT obviously can't rollback sending notifications, so it makes sense
to do it after all the things that can be rolled back are done.

* Notifications can't "see" CF and status changes made via the web UI
when they fire.

eg, in a recent ticket:

Fri, 19 Jul 2013 23:02:00 +0800 The RT System itself - Outgoing email
recorded [Show]
Fri, 19 Jul 2013 23:02:00 +0800 The RT System itself - Outgoing email
recorded [Show]
Fri, 19 Jul 2013 23:02:00 +0800 Some User - Status changed from 'new' to
'open'
Fri, 19 Jul 2013 23:02:00 +0800 Some User - WaitingOn Customer added

where "WaitingOn" is a CF with values "Customer" or "Support".
Transaction numbers increase down the page. The CF is set using the
extension RT::Extension::CustomFieldsOnUpdate, but the Status is of
course set by the core code.

The order of events logged in the "Results" tab after Update.html runs
and redirects to Display.html is:

[Results]
Message recorded
Ticket xxxx: Status changed from 'new' to 'open'
WaitingOn Support changed to Customer

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services