TransactionBatchStage: Difference between revisions
m (6 revisions imported) |
(No difference)
|
Revision as of 15:39, 6 April 2016
Introduction
ScripExecOrder article gives you overview and example about what "stages" is and what happens if scrip in batch stage instead of create stage.
In two words: If Scrip in batch stage then it's applied only when all transactions of the user's request have been created.
When do you want to use batch stage
- When people resolve tickets they can write a comment, in some setups it's cool to send a notification that the ticket is resolved to requestor and add the comment to the email. RT allows user to leave comment blank or RT as well could create a resolve transaction earlier than a transaction for the comment. In this situation batch stage can help you, you can find example of a template below.
- Another situation when you need batch stage is custom field updates. Consider some page with custom fields change boxes and fields for other manipulations and for example you want set field X on status change. RT sets status (create transaction) in create stage your scrip updates a CF, but then RT reverts this change as it starts CFs update action which checks if object has values in arguments of the request, the new value is not there then RT deletes it.
- Keep in mind that if your TransactionBatch scrip sends email, the email address of the people notified will not be visible while users are composing a reply.
How to enable it?
Add to RT_SiteConfig.pm (only needed in RT versions less than 3.8.2 which defaultes this to on)
Set($UseTransactionBatch , 1);
Then restart server to apply changes and now you can set stage for scrips you want to run in batch stage.
How it works?
This is complex Template that adds "last" comment to email. Template works in both stages, but works better in batch stage cause adds only comment that was added within resolve action only.
-------------------- Clever 'resolved' template ---------------------- Subject: Resolved: {$Ticket->Subject} According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. { my $old_user = $Ticket->CurrentUser; $Ticket->CurrentUser( $RT::SystemUser ); my $batch = $Ticket->TransactionBatch; my $comment; if( !$batch || !ref($batch) ) { $RT::Logger->info("TransactionBatch stage is disabled, fallback to last comment. Turn on TransactionBatch stages for acurate results."); my $transactions = $Ticket->Transactions; $transactions->Limit( FIELD => 'Type', VALUE => 'Comment' ); $transactions->OrderByCols( { FIELD => 'Created', ORDER => 'DESC' }, { FIELD => 'id', ORDER => 'DESC' } ); $transactions->RowsPerPage(1); $comment = $transactions->First; } else { $comment = (grep { ($_->Type eq 'Comment')? 1: 0;} @$batch)[0]; } $OUT = " "; if ( $comment ) { # Since we're effectively turning this comment into # correspondence, it is possible to use RT::Record to alter # history a bit here. This is normally really frowned upon, # but without this, users may be confused that the reply they # got by email isn't visible in the Web UI, because they don't # have the ShowTicketComment right RT::Record::_Set($comment, ( Field => 'Type', Value => 'Correspond' )); $OUT = "Resolution:\n"; $OUT .= ("-"x76) ."\n"; $OUT .= $comment->Content; } $Ticket->CurrentUser( $old_user ); }
You can set the stage on your scrip from the Applies To page in 4.2, or from the Scrip page in 4.0. In 4.2 you can even choose to run scrips in TransactionBatch mode on a per-queue basis.
See also the Initialdata docs