Example, our news server crashes and we get 5 email asking why they
can’t reach it. I want to merge them all into one message so that I
can send a reply as to the damage, and later a reply saying it’s
back up.
If I merge them now, send out the explanation, and a user replies, it goes
to all users. I don’t want this to become a mailing list for many
reasons…
So I want the reply to just come to our email address, and not go to
others. However, if I remove them as requestors, I lose the ability
to send out the Mass reply when it’s back up.
Is there a way to create a setup that allows this usage? Thanks in
advance.
I don’t think there’s a way to do exactly what you want,
It could be done with some scrips cooked up for just that purpose.
Firstly you need to make sure that you never give out requestors’
addresses to each other. Currently RT::Action::Notify will put all
requestors in the To: header, anybody could choose the ‘reply to all’
function in her/his mailer and spam the other people.
This couldn’t happen if the addresses were put in the Bcc: header.
There are circumstances at the moment where RT::Action::Notify uses Bcc:
for some people – not requestors, but it’d be a simple change to make.
The second problem comes from a scrip such as:
OnCorrespond Notify Requestors
If one of your requestors replies to the ticket, all the other
requestors will get mailed. (And if you don’t have such a scrip, you
won’t be able to mail them in the first place.) So you need to be able
to distinguish you sending correspondence from requestors doing so.
You could have a scrip that looked to see whether a message’s author is
internal (has a particular format of e-mail address, or has particular
‘RT’ permissions), or it’s possible that just distinguishing how the
message was sent would be sufficient (web interface: distribute to
everybody; e-mail: don’t propagate to requestors). Look in contrib for
scrips that’ll help you make this distinction.
but the way we address a similar issue is to have a ‘parent’ ticket
with all the individual ones as children.
Having said that what Sera wants is possible, Qef’s advice is still
probably saner. Since these are separate requests, it makes sense to
keep them as separate tickets, but operate on them together.
You can do a search for the children and reply to all of them at once
The bulk ‘update all these tickets at once’ feature will also allow you
to make other changes, such as resolving them all together too.
Of course, this is a lot of work to manage
The bulk update link is available for processing tickets listed in
search results, but there isn’t an easy way of searching for tickets by
relationships.
To deal with this I’m thinking of adding a ‘child bulk update’ link to
the display of parent tickets. Basically if a ticket has children then
as well as listing them it provides a link which will go to the bulk
update screen with the child tickets as the ones to be bulk-updated.
If I get round to this, I’ll post to the list.
Smylers
GBdirect