[rt-users] email filter that sets ticket via subject lookup?

[Kenneth Marshall]

On Fri, Oct 09, 2009 at 09:27:15AM -0400, Kevin Falcone wrote:
> On Thu, Oct 08, 2009 at 11:12:11PM -0500, Robert Eden wrote:
> > On 10/8/2009 9:02 AM, Kevin Falcone wrote:
> > > On Wed, Oct 07, 2009 at 11:24:50PM -0500, Robert Eden wrote:
> > >   
> > >> Howdy All.
> > >>
> > >> We work with a vendor and store the vendor's ticket # in a custom field.
> > >>
> > >> We'd like to be able to add a comment to the RT ticket by "cc"ing  RT on 
> > >> vendor email. The subject of the message contains the vendor ticket 
> > >> number, and I'll determine the RT # via a search.
> > >>     
> > ....
> > > You may just want to borrow the Nagios scrips on the wiki and On
> > > Create find the existing ticket you need to merge into and set the CF
> > > from there.  You'll find the Scrip Action interface to be a lot easier
> > > to do what you need (since the tickets exist and you can set
> > > properties).
> > 
> > Thanks for the idea Kevin...  I got a modified scrip working. That 
> > solution takes the new ticket and merges it with my main one.  It works, 
> > but you have the side-effect of potentially a lot of extra tickets and 
> > also additional "requestors" because they're merged.
> > 
> > Is there any way to avoid the new ticket with new requestor?  I get the 
> > feeling the ticket is already created by the time "on-create" hits, so 
> > that damage is already done. 
> 
> Tickets must exist for Scrips to run on them
> 
> > One solution is to extract the text and add the comment to the other 
> > ticket and then change the status of the newly created ticket to 
> > "delete".  I still get an extra ticket, but at least it doesn't do much 
> > harm.  I'm leaning towards that.. I guess it's cleaner than intercepting 
> > it at the mail entry.
> 
> I'm not sure what this buys you over merging the ticket (which
> effectively makes the new ticket disappear into the old ticket) but if
> it helps you manage your Requestors, then go for it
> 
> -kevin

Has the performance problem with many merged tickets been resolved?
If not, this method will perform better instead of taking much time
and CPU to pull up a ticket with many, many merges.

Regards,
Ken