[rt-users] RIP tickets

[Dominic Lepiane]

We don't want to remove the data from old tickets, so I don't think RTx::Shredder will work in our case.

We could try moving old tickets to an archive queue that doesn't email out and preferrably doesn't allow closed tickets to be opened.  How can we go about doing this?

Thanks in advance,

Dominic Lepiane


> -----Original Message-----
> From: gordon at cryologic.com [mailto:gordon at cryologic.com]
> Sent: Sunday, May 25, 2008 5:14 PM
> To: RT Users
> Cc: Dominic Lepiane
> Subject: Re: [rt-users] RIP tickets
>
> How about moving all tickets of a certain age to a separate
> (archive) queue which has reply to requestor scrips disabled.
>
> Gordon
>
>
> Dominic Lepiane wrote:
> > Hi,
> >
> > We've been using RT for many years now and an issue has
> recently come to my attention regarding old tickets being
> re-opened.  Specifically, when dealing with RMAs, we have
> both an RT ticket number and an separate tracking number for
> another system.  As it turns out, the RT ticket numbers are
> all 5 digits these days (going on 6) and the other number is
> 4 digits.  What happened was that by human error, the numbers
> can be mixed up whereby an arbitrary and very old RT ticket
> gets reopened when someone tries to update the RMA ticket.
> Which is not a problem per se, support staff just close the
> ticket again, however, RT then emails out this customer from
> 5 years ago.
> >
> > So we were wondering if we can somehow catch emails
> referring to very old closed tickets and do something else
> with them.  Either email them to someone in particular, open
> up a new ticket, drop them altogether or possibly find the
> correct ticket based on the custom field which contains the
> 4-digit ticket number from the other system.
> >
> > Can we do this and what are we looking at doing to do this?
> >
> > If nothing else, I would like to intercept all messages to
> tickets < 10000 and redirect those emails to a separate
> mailbox which I can probably do in procmail (if my fu is strong).
> >
> > Thanks in advance
> >
> > Dominic Lepiane
> > Network Administrator
> > Point Grey Research
>
>