[rt-users] Dealing with people who send email to Helpdesk andCCothers

Fri Mar 4 18:59:34 EST 2005

One thing I meant to mention as well is the following 'asymmetrical' behavior:

Once the Watcher list is set up via RT Web interface, *then* it is ok to conduct collaborative communication via email -- with the caveat that only the RT-queue email address is the email recipient and the Subject line contains the '[rt-queue #123]' (or something like that) tag.  

Again, as far as people who are collaborating on a particular RT request are concerned, email replies should be sent to RT queue email address only.  RT server is the one that will forward the email mesg to the people on the Watcher list for that ticket.

It's kinda weird that you have to manage Watcher list via RT Web interface, the but actual communication amongst the people can be done either via the web interface or email.  It would be nice if I can do all that via email, but I don't think it's possible (without some heavy hacking made to RT).

Pei

> -----Original Message-----
> From: rt-users-bounces at lists.bestpractical.com
> [mailto:rt-users-bounces at lists.bestpractical.com]On Behalf Of Pei Ku
> Sent: Friday, March 04, 2005 3:45 PM
> To: Fran Fabrizio; rt-users at lists.bestpractical.com
> Subject: RE: [rt-users] Dealing with people who send email to Helpdesk
> andCCothers
> 
> 
> Hi,
> 
> I ran into the same issue a few months ago when I first deployed RT.  
> 
> After thinking through it and experimented with several 
> workarounds (both technical and process-based), I have 
> reached the following conclusions.
> 
> Well, before I get into my conclusions, let me make sure I 
> understand what you are trying to do:
> 
> Why did Jeff CC Barrett, Tony, and John in the original email 
> sent to RT-helpdesk in the first place?  Is it because you 
> simply want those CC'ed people to be aware of the request, or 
> do you anticipate those CC'ed people to add correspondences 
> to the request because they may have additional info or 
> comments to add during the request's life cycle?
> 
> If it's the latter, then we are dealing with the same issue.  
>  This is what I called a type of 'collaborative' workflow: in 
> the colloaborative workflow, the requestor initiates a 
> request where he wants other parties (in addition to himself 
> and the request taker) to participate in the life-cycle of 
> the request.  In fact, this is the main reason I installed RT 
> in order to improve and track some of the collaborative 
> processes in the company I work at.
> 
> As you noted in your problem discription, the 'intuitive' 
> behavior from the users using RT via email will lead to to 
> creation of duplicated RT ticket.  
> 
> Contrast collaborative workflows to 1-on-1 simple workflows: 
> requestor generates a request, queue admin takes the request 
> and resolves it (possibly after some back-and-forth 
> correspondences), everyone lives happily ever after.
> 
> I have concluded that use of RT via email and collaborative 
> workflow are incompatible at this point.  The fundamental 
> problem is that, if you want to use RT to support 
> collaborative workflows, the CC list (or Watcher list, in 
> RT's nomenclature) needs to be stored in RT repository, 
> rather than being managed by ther users in their email 
> client's cc field.  You have that kind of control only 
> through the RT Web interface.
> 
> In fact, I have established a RT usage policy in my company 
> which states that, when you submit a new ticket to RT, do NOT 
> specify any CC list.  If you do want to include other people 
> in the life cycle of a request, in the BODY of the email, add 
> the line "Notify: Bob, Joe, Susan" at the first line in the 
> body.  The request taker, upon seeing that Notify list, will 
> set up RT watchers via the RT web interface.  
> 
> I'm also trying to train the users to use RT web interface to 
> create the ticket;  in the web interface, you can set up the 
> Watcher list yourself.  This approach offloads the Watcher 
> list management from my queue admins, but so far I haven't 
> been able to convince all users to do that yet (submitting a 
> new RT request via email is a lot easier).
> 
> In RT 3.2.2, the CC list field in Create Request web page is 
> a free text field where you are supposed to entered the list 
> of comma-delimited email addresses of the Watchers you want 
> to set for the ticket.  If you type the wrong email 
> addresses, RT will create RT accounts for them if they are 
> not existing RT users.  I hacked the Ticket.pm module (I 
> think) so it does some extra check and would not allow any 
> unknown RT user email addresses in the Watcher field.
> 
> But then there is the issue with email aliases.  In our MS 
> Exchange server, we have convenient 'pseudo' email accounts 
> like qa at mycompany.com, developers at mycompany.com, etc.  I need 
> to create RT users with these email addresses.  But then I 
> can't really control certain group-based access control 
> anymore, since the RT user 'qa at mycompany.com' is not the same 
> as the group of RT users who are in the QA group.   I could 
> (and did) create a RT group that contains the QA users, but 
> then the user needs to think about whether they should use 
> 'qa at mycompany.com' or use the QA group in RT when setting up 
> the Watchers -- not all my users have CS degree :-)
> 
> Anyway, it's an interesting problem for which I don't see a 
> clean solution at this point.
> 
> Pei
> 
> 
> 
> 
> > -----Original Message-----
> > From: rt-users-bounces at lists.bestpractical.com
> > [mailto:rt-users-bounces at lists.bestpractical.com]On Behalf Of Fran
> > Fabrizio
> > Sent: Friday, March 04, 2005 8:11 AM
> > To: rt-users at lists.bestpractical.com
> > Subject: [rt-users] Dealing with people who send email to 
> Helpdesk and
> > CCothers
> > 
> > 
> > 
> > What's the best way to avoid this scenario:
> > 
> > 1.  Jeff sends a note with subject "Machine Broken" to 
> > Helpdesk and CC's 
> > Barrett, Tony and John.
> > 2.  Helpdesk opens a ticket titled "Machine Broken" with Requestors 
> > Jeff, Barrett, Tony, John and sends a receipt to Jeff with subject 
> > "[Helpdesk #2008] Helpdesk Update: Machine Broken" to note 
> > that it has 
> > received your request.
> > 3.  Barrett does Reply All to Jeff's note "Machine Broken". 
>  When he 
> > does this, his "Re: Machine Broken" reply will go to Jeff, 
> Tony, John 
> > and Helpdesk.
> > 4.  This opens another ticket in the Helpdesk titled "Re: Machine 
> > Broken" and Barrett will receive a receipt from Helpdesk 
> with Subject 
> > "[Helpdesk #2008] Helpdesk Update: Re: Machine Broken".
> > 5.  Tony then replies to Jeff's note.  Yet another ticket is 
> > created.  
> > Etc....
> > 
> > Right now I enable $ParseNewMessageForTicketCcs but I'm not 
> sure that 
> > setting comes into play here.  The real issue is that people 
> > are used to 
> > doing Reply All, and don't bother to see if Helpdesk is one of the 
> > people they are replying to. 
> > 
> > I can't figure out a graceful way to handle it.  I want to be 
> > including 
> > all of those others on the ticket, but I don't want their 
> > replies to be 
> > opening new tickets.  Even if I don't ParseNewMessageForTicketCcs, 
> > they'll still open duplicate tickets when they do Reply All.  
> > Is there 
> > anything to be done here?
> > 
> > Thanks,
> > Fran
> > 
> > -- 
> > Fran Fabrizio
> > Senior Systems Analyst
> > Department of Computer and Information Sciences
> > University of Alabama at Birmingham 
> > http://www.cis.uab.edu/
> > 205.934.0653
> > 
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> > 
> > RT Administrator and Developer training is coming to your 
> > town soon! (Boston, San Francisco, Austin, Sydney) Contact 
> > training at bestpractical.com for details.
> > 
> > Be sure to check out the RT Wiki at http://wiki.bestpractical.com
> > 
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> RT Administrator and Developer training is coming to your 
> town soon! (Boston, San Francisco, Austin, Sydney) Contact 
> training at bestpractical.com for details.
> 
> Be sure to check out the RT Wiki at http://wiki.bestpractical.com
> 