Merging and Replies

We are using 2.0.14, and overall quite pleased. I started messing with the
Merge option but found that it has some functionality that makes it useless
for us, unless I can figure out a way to modify it. I’ve tried several
things but nothing works as we need yet.

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… one the potential for abuse, two I don’t want to flood users
mailboxes with “Thanks for the help” from other users, etc…

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.

We are using 2.0.14, and overall quite pleased. I started messing with the
Merge option but found that it has some functionality that makes it useless
for us, unless I can figure out a way to modify it. I’ve tried several
things but nothing works as we need yet.

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… one the potential for abuse, two I don’t want to flood users
mailboxes with “Thanks for the help” from other users, etc…

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, but the way
we address a similar issue is to have a ‘parent’ ticket with all the
individual ones as children. You can do a search for the children
and reply to all of them at once, or just an individual one.

Of course, this is a lot of work to manage, so it might be more efficient
to deal with the tickets individually.

Qef

— Geoff Richards -------><------- www.rosies-dumplings.co.uk/qef
“I tried to fling my shadow at the moon,
The while my blood leapt with a wordless song.” – Theodore Roethke

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

Smylers wrote:

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.

How about making the “From” address for a correspondence the "-comment"
address for the queue? That way the replies don’t get out to any other
requestors.

Rob

Rob W.W. Hooft || rob@hooft.net || http://www.hooft.net/people/rob/