Ticket # configurations

Greetings,

I am pretty new to RT. It seems like a great program. I have skimmed through the archives but was unable to find much information about customizing the Ticket number to be specific to each queue.

For example:

Queue 1: Tickets would start with an "A"
Queue 2: Tickets would start with a “B”

Thanks,

David Bauman
ANET Internet Solutions

David Bauman wrote:

Queue 1: Tickets would start with an "A"
Queue 2: Tickets would start with a “B”

What would happen if a ticket was moved from queue 1 to queue 2?
Phil Homewood, Systems Janitor, http://www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

Good question. I would want it to rename/renumber the ticket and notify with the ticket move. For the purpose I am looking for though, it would not be necessary to move a ticket between queues.----- Original Message -----
From: Phil Homewood
Sent: 7/13/2003 6:13:34 PM
To: rt-users@lists.fsck.com
Subject: Re: [rt-users] ticket # configurations

David Bauman wrote:

Queue 1: Tickets would start with an "A"
Queue 2: Tickets would start with a “B”

What would happen if a ticket was moved from queue 1 to queue 2?

Phil Homewood, Systems Janitor, http://www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Good question. I would want it to rename/renumber the ticket and notify
with the ticket move. For the purpose I am looking for though, it would
not be necessary to move a ticket between queues.

if I remember correctly, good database design recommends that table keys
should be as devoid of external meaning as possible – it should be an
identifier for a row in the table, and nothing more.

Having RT ticket id’s be nothing more or less than a unique identifier for
a given ticket is very much in keeping with this line of thought. It
shouldn’t be taken as dogma – there can be good arguments to make an id
be something meaningful (keying a website’s user id off her email address,
for example), but good arguments against it as well (that user changes her
address, or as in this case, a ticket gets re-queued).

If you really want to implement this, it may prove necessary to come up
with a second ID field so that queue A ticket A1234 is the same matter
that was previously referred to as B5678 under queue B. And at that point,
you may as well go back to just leaving the ID alone.

Rather than tinkering with the raw ticket id, maybe what you want to do
could best be implemented as one of RT3’s custom fields?

Chris Devers cdevers@pobox.com

-ready suffix
1 Available now at extra cost, as in “monitor-ready,” "RAM-ready."
2 Available at some future date for an unspecified cost, as in “AI-
ready.” Compare -AWARE.

-- from _The Computer Contradictionary_, Stan Kelly-Bootle, 1995