[rt-users] Merging and Replies

[Smylers]

On Tuesday Geoff Richards wrote:

> On Mon, Oct 28, 2002 at 09:21:37PM -0700, Sera wrote:
>
> > 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
http://www.gbdirect.co.uk/