I’m setting up RT for a department with multiple administrative domains
(this is my criteria: if a group has its own manager, it deserves a
queue). By default, ticket cardinality seems to be an attribute of the
global RT instance. I think it would be more elegant if it were an
attribute of the queue. For example, (assuming 3 example queues) I would
like the following three ticket subject lines to make sense:
I think what I want is for the global AutoReply template to contain
something like:
[{$queuename} {$rtname} #{$Ticket->id}]
(or whatever should be used for $queuename) rather than
[{$rtname} #{$Ticket->id}]
but this doesn’t seem to address the independent ticket numbers per
queue. It seems to me like most people would rather configure RT the way
I described above, so I assume I’m just missing something.
By default, ticket cardinality seems to be an attribute of the
global RT instance. I think it would be more elegant if it were an
attribute of the queue. For example, (assuming 3 example queues) I would
like the following three ticket subject lines to make sense:
The (one?) problem with having ticket IDs be per-queue is that tickets
are stored by ID (and things like attachments reference them by such),
and they can move between queues. It seems to me your suggestion would
involve a fairly intensive find-and-replace when moving a ticket from
one queue to another. This would be a huge issue for us (and I
suspect others), as we’re constantly moving tickets that people have
dropped into the “General” queue into a more appropriate home.
Aside from that predicted performance issue, I find it convenient to be
able to say “ticket 27” and have it be clear what I’m talking about.
Keep in mind you can also reference tickets in other queues.
Anthony Sorace
CIBERNET Corp
Director of Information Technology
I’m setting up RT for a department with multiple administrative domains
(this is my criteria: if a group has its own manager, it deserves a
queue). By default, ticket cardinality seems to be an attribute of the
global RT instance. I think it would be more elegant if it were an
attribute of the queue.
what happens when you move a ticket between queues? In my world view,
tickets should have unique numbers per install. If you want really
separate queues, maybe you want separate RT installs?
The (one?) problem with having ticket IDs be per-queue is
that tickets
are stored by ID (and things like attachments reference them
by such),
and they can move between queues.
To rephrase Anthony’s answer more bluntly:
To do this cleanly, it would involve a huge redesign, touching most
parts of RT. If you really want this behavior, install multiple
instances. I’d suggest just accepting it.
By default, ticket cardinality seems to be an attribute of the
global RT instance. I think it would be more elegant if it were an
attribute of the queue.
Jody Belka wrote:
What should the system then do if you move a ticket from one queue to
another?
Ah, that is not something I had considered (nor something my model
requires, but I can see why others would want to).
The main thing that I wanted to accomplish was to have the queue name
clearly on the subject line.
I changed the global Autoreply template subject line to:
what happens when you move a ticket between queues? In my world view,
tickets should have unique numbers per install. If you want really
separate queues, maybe you want separate RT installs?
The way this is normally* handled is that database-internal unique IDs are
not exposed. Every ticket has a unique ID, and a queue ID. If a ticket
moves between queues, you Do Something to make it unique, such as
renumbering it, appending something, or whatever.
I’m not denying that this would be a huge change for RT; I’m just
illustrating what other applications that have encountered this sort
of problem do.
-j
*This causes other problems, such as users expecting that the ID they
see is actually the ID of the record, leading to other conclusions about
internal software states, causing lots of confusion all around. Ain’t
software grand?
Jamie Lawrence jal@jal.org
“Saying ‘please’ is for losers”
-Joe Tucci
I’m setting up RT for a department with multiple administrative
domains (this is my criteria: if a group has its own manager, it
deserves a queue). By default, ticket cardinality seems to be an
attribute of the global RT instance. I think it would be more
elegant if it were an attribute of the queue.
seph wrote:
what happens when you move a ticket between queues? In my world view,
tickets should have unique numbers per install. If you want really
separate queues, maybe you want separate RT installs?
Maybe. I don’t think it would be that difficult; probably just a new
Apache virtual host and I guess you would need another RT hierarchy so
you could have a unique RT_SiteConfig for each instance. That would be
using different RT instances to model different departments rather that
queues which seems cleaner. Of course, a new database, but that is easy.
I will probably just stick with my template hack and explain to
individual queue users why the ticket numbers seem to jump around. I
also need to figure out how to add the queue name into the subject line
of responses from staff members also; I expect that should be easy.
BTW, I’ve been working on some internal documentation to make all of
this work with RT 3, OpenBSD 3.4, postfix, and PostgreSQL. It ended up
being pretty general, so I’ll probably post this document when I’m done.
what happens when you move a ticket between queues?
The way this is normally* handled is that database-internal unique IDs are
not exposed. Every ticket has a unique ID, and a queue ID. If a ticket
moves between queues, you Do Something to make it unique, such as
renumbering it, appending something, or whatever.
except that there must be an exposed unique id, otherwise the system
(RT or otherwise) can’t route things to the right place. For example:
user sends mail to support, gets autoresponse with [support #36]
staff member decided it really belongs to billing, ticket is
now [billing #29]
user sends some additional informational mail, to their tag
of [support #36]
How does the system know where to route it?
That’s the part in capitals (“Do Something”). Like renumbering it,
appending something, or whatever. I was speaking to the general problem,
which is identifying a unique instance of something, when multiple
methods of referring to that something might apply. Handling the
indirection is a different problem than identifying the original thing,
and if you’re interested in scaling, that’s important.
As far as this particular case goes, it depends on goals. If you (for
some business reason) need consecutive tickets, then of course you have
to add something else, and do something like [billing #363f9a85], or
whatever. If you don’t, you have a primary key of the two identifiers.
None of this has anything to do with RT development, and I apologize for
leading in a direction that was not applicable.
-j
Jamie Lawrence jal@jal.org
“In human stupidity, when it is not malicious, there is something
very touching, even beautiful… There always is.”
-Leo Tolstoy
