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
Do any of the other RT users here know of a reason not to use
TransactionBatch for sending email notifications?
TransactionBatch Scrips do not show up in the Preview Scrips UI, so
you’ll be unable to squelch users either at the Ticket or Transaction
level.
-kevin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On 07/23/2013 09:00 PM, Kevin Falcone wrote:
On Tue, Jul 23, 2013 at 03:56:49PM +0800, Craig Ringer wrote:
Do any of the other RT users here know of a reason not to use
TransactionBatch for sending email notifications?
TransactionBatch Scrips do not show up in the Preview Scrips UI,
so you’ll be unable to squelch users either at the Ticket or
Transaction level.
Thanks for the tip. I don’t think that matters much for my particular
use, but it’s good to have on record here for others who’re trying to
find out about the same issue later.
Would you be potentially inclined to accept a patch that recorded the
message after the status and other attribute changes - or would that
be too likely to break other things?
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJR71SSAAoJELBXNkqjr+S2QLMH/0VqQAig1efaAJJilkFh+4RF
HvHcIbpSsWlR2GduZaJvyoCqdtU6Ifc/fV3IbPC3fOfCl/2p0r+spq+NnYJaKJV9
of9ENB/HJB5Gye/ihR1FFDloZleKDm/WtqenVeZaykAMVwwPQwszJrMjj4hjhq80
dO/J6RHGeJVMbxMRyDz9FmdSSbyTQ9m+mHquCZOkHjFbHJUVm2V44Zp0Jlgpu5r7
MfMRpfgZVt7wHi/6AlJqYDci8NGnzbRz+py4LHf5poMp2rstSqCqYfsgq2kqKxO1
sSKddyAt+LjxYShBzzLkhaCG+3bEJkbS0cymm3InAHR3OoXDq9I6pgxEt+3bTIo=
=adr/
-----END PGP SIGNATURE-----
Do any of the other RT users here know of a reason not to use
TransactionBatch for sending email notifications?
Be wary of $self->TransactionObj in TransactionBatch scrips; it isn’t
guaranteed to be the transaction that matched the scrip condition but
merely the first transaction in the batch.
You can use $self->TicketObj->TransactionBatch to get an arrayref of
transaction objects.
Do any of the other RT users here know of a reason not to use
TransactionBatch for sending email notifications?
Be wary of $self->TransactionObj in TransactionBatch scrips; it isn’t
guaranteed to be the transaction that matched the scrip condition but
merely the first transaction in the batch.
You can use $self->TicketObj->TransactionBatch to get an arrayref of
transaction objects.
Thank-you very much for that tip.
I’m compiling a pile of RT extension/development notes that I’m working
on merging into the perldoc; I’ll hopefully have a patch for you to pick
and choose from in a few weeks.
Considered adding a warn(…) line in TransactionObj() when invoked in
batch context?
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Please respect my Reply-To headers, I set them to the list because I
read all mail sent to the list. There is absolutely no need to CC me.
Do any of the other RT users here know of a reason not to use
TransactionBatch for sending email notifications?
TransactionBatch Scrips do not show up in the Preview Scrips UI,
so you’ll be unable to squelch users either at the Ticket or
Transaction level.
Thanks for the tip. I don’t think that matters much for my particular
use, but it’s good to have on record here for others who’re trying to
find out about the same issue later.
It’s already on record. I explain it frequently when folks reach out
to TransactionBatch for the wrong reasons.
Would you be potentially inclined to accept a patch that recorded the
message after the status and other attribute changes - or would that
be too likely to break other things?
That would never be accepted into a stable series. It would be
considered for a dev series, but frankly I’ve always been able to get
the info I want in a TransactionBatch scrip, even if lots of things
are happening during the update. I also expect that if you read back
through the commit history, you’ll find reasons for the ordering.
A trivial On Correspond Notify Requestors that does
$self->TicketObj->FirstCustomFieldValue(‘foo’)
in the template works just fine and dandy for me.
-kevin