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 email@example.com
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