I am using rt the organize a conference program with around 600-700 submission, and need to send acceptance and rejection mails in bulk. I am using both, some hand written python code and the ruby gem roust as plugin to the frab conference planning tool to set Owners, change Subjects and add Correspondence.
Unfortunately, each of those transactions triggers several emails to the Owner, resulting in email storms in the range of 10000s to my event coordinators, that I need to manually filter all mails to the coordinators in postfix. If they happen to also submit to the conference, their acceptance mails will be removed and all notifications to replies to those new correspondences will not reach the coordinators until I remove the postfix filter. Obviously, this is not a good solution.
While in RT’s HTTP interface you can set TxnRecipients to squelch e.g. the Owner, the corresponding parameter is not processed in the REST or REST-2.0 API.
Is there a recommended way to interact with RT to avoid these email storms or would it be possible to make squelching available via one of the REST APIs?
There’s multiple batches of automated notifications. Between those runs, Owners need to get email notification about Correspondence added by the Requestor. It’s just the notifications triggered by the script that I want to squelch.
Is it possible that you can call the rt-crontool from something like your Python script? Instead of calling the correspond endpoint from the REST api to update the requestor you’d call something like /opt/rt4/bin/rt-crontool --search "RT::Search::FromSQL" "id=1234" --action RT::Action::NotifyGroup --action-arg 'Requestors' --transaction --last --template 'some template from CLI to send the email
That might work for the script, even though it currently runs from another machine, I would need to rework it to generate lists of these commands, get the escaping right and dig deep into the perly bits of RT. Sounds like too much work just to avoid notifications. And the python script only is used to set Owners and add internal comments.
The conference management tool itself, however is a huge rails app that uses SuckerPunch to iterate over all recipients, manually set each one of them as Requestor, fixes the Subject, add correspondence and in the end resets the Subject and Requestors. All of that over “REST”/HTTP from a host I do not really control most of the time. This is not something I can easily add there.
But maybe I can look into the scrips to talked about in the beginning and disable the notify magic while the bulk jobs run?
How about checking the X-RT-Interface header and if it is REST do not do the normal correspond, then have a new scrip that does a normal correspond but only to requestor if the interface is REST. I believe in the scrip condition you can add something close to this $self->TransactionObj->Attachments->First->GetHeader('X-RT-Interface') to test how the correspond is being created.
Do you need the original outbound emails in RT? When I ran a conference, I had all the reply-to email address set to RT, but for the mail merge outbound stuff I just Bcc to an archive mailbox. That way I captured any replies.