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

Pei Ku pku at autotradecenter.com
Fri Mar 4 18:45:26 EST 2005


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
> 



More information about the rt-users mailing list