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