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

[Bob Goldstein]

>
>
>User1 sends an email to user2, user3, and helpdesk.
>User2 "reply all"s to user1's email, sending an email to user1, user3, 
>helpdesk.
>Two tickets have just been created.


   Right.  Here, RT will send the auto-reply  to all the users.
   So User2 now has the original note from user1, as well
   as RT's "Thanks for the ticket, here's how to deal with it."

   Since RT is fast, probably User2 has both notes pretty much
   simulateously.  Obviously he should reply to the second
   only.  Sometimes mistakes happen, but in practice here,
   it hasn't been too bad.  If user2 reads both before replying
   to either, you have a fighting chance.

   We _have_ had it happen a few times, where user3 was
   actually a separate, non-RT helpdesk!  Dueling helpdesks
   can create quite a few new tickets before I was able
   to hit the STOP button :-)

      bobg


>
>Turning off the ParseNewMessageForTicketCcs won't help at all here.
>
>Besides user training to scan the email recipients and realize the 
>ramifications of having helpdesk in the recip list, is there anything 
>that RT can do to prevent this?  Such as figuring out that "Re: Foobar" 
>as a subject line might be related to the "Foobar" subject line that it 
>just turned into a ticket earlier that day? 
>
>Maybe I should just have procmail drop anything headed to RT that has 
>Re: in it without an RT tag.  Seems kludgy though and will definitely 
>kill some legitimate attempts to make a ticket.
>
>-Fran
>
>Drew Barnes wrote:
>
>> # If $ParseNewMessageForTicketCcs is true, RT will attempt to divine
>> # Ticket 'Cc' watchers from the To and Cc lines of incoming messages
>> # Be forewarned that if you have _any_ addresses which forward mail to
>> # RT automatically and you enable this option without modifying
>> # "RTAddressRegexp" below, you will get yourself into a heap of trouble.
>>
>> Set($ParseNewMessageForTicketCcs , undef);
>>
>> # RTAddressRegexp is used to make sure RT doesn't add itself as a 
>> ticket CC if
>> # the setting above is enabled.
>>
>>
>> Fran Fabrizio wrote:
>>
>>>
>>> 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
>