Hello,
I’m trying to set up a number of queues in RT3. They should be separated
from each other. I’ve set them up under different mail addresses,
different queue names etc. - this works fine, but the Subject:-Tag is, I
guess, rt->rtname (add some Perl sugar if needed).
How can I change the Subject:-Tag to be something like
[$queuename # $ticketnumber]?
What do I break if I change this in RT’s code (upgrade hassles aside)?
Regards,
Matthias
How can I change the Subject:-Tag to be something like
[$queuename # $ticketnumber]?
What do I break if I change this in RT’s code (upgrade hassles aside)?
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.
Generally, these tags are opaque globally unique identifiers for your
tickets, not something humans need to make any sense of.
Sebastian
Sebastian Flothow
sebastian@flothow.de
Because it reverses the logical flow of conversation.
Why is top posting frowned upon?
Sebastian Flothow wrote:
[$queuename # $ticketnumber]?
What do I break if I change this in RT’s code (upgrade hassles aside)?
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.
OK, that’s definitively too much to work around.
Generally, these tags are opaque globally unique identifiers for your
tickets, not something humans need to make any sense of.
But they do read it when it’s in the Subject. – What I’m now doing
might not be too elegant:
RT_SiteConfig.pm:
| Set($rtname , “Ticket”);
This results in “[Ticket #nnn]” as subject-tags. I can live with the “RT
for Ticket” in the top bar of the web interface.
– Matthias
Am Freitag, den 18. Juli 2003, um 11:56, schrieb Matthias Leisi:
How can I change the Subject:-Tag to be something like
[$queuename # $ticketnumber]?
What do I break if I change this in RT’s code (upgrade hassles aside)?
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.
This could be worked around with [sitename . queuename .
#.ticketnumber].
Generally, these tags are opaque globally unique identifiers for your
tickets, not something humans need to make any sense of.
I see that this is how RT uses the subject line, but I think that this
is a broken implementation of this concept.
My thoughts are that opaque things should not be seen by humans. The
subject line is certainly displayed by every mail tool that I have ever
seen.
I think a better implementation of “not-for-human-consumption” data
might have been to use X-RT-* headers liberally.
X-RT-Version
X-RT-Ticket-ID
X-RT-Queue-Name
All could be useful headers, if the designers find a use for them. This
would also allow per-queue subject tags to be created, and manipulated,
as desired.
Of course, an email which appeared on the mailgate’s doorstep without
the X-RT-* headers and with only a subject header would need to be
handled appropriately.
I think that the best way to get this option implemented is to find out
how much $$$ it would take bestpractical to do the work, and then start
working with the other people who have asked for this functionality
(queue-based names) to get together to pay for it. So far, none of my
clients need it bad enough. 
Maybe the marketing people at bestpractical will find this an
opportunity to add this feature at a new install. I don’t know.
rob
I think a better implementation of “not-for-human-consumption” data
might have been to use X-RT-* headers liberally.X-RT-Version
X-RT-Ticket-ID
X-RT-Queue-Name
As those header almost certainly won’t make it back to RT once they have
been sent to the user, it may be better to have (unique|opaque)
identifiers coded into a mail address, e.g.
I think that the best way to get this option implemented is to find out
how much $$$ it would take bestpractical to do the work, and then start
working with the other people who have asked for this functionality
(queue-based names) to get together to pay for it.
Good thought 
– Matthias
Generally, these tags are opaque globally unique identifiers for your
tickets, not something humans need to make any sense of.I see that this is how RT uses the subject line, but I think that this
is a broken implementation of this concept.
I’ll agree it’s a little ugly, but I don’t find it broken. It’s also
pretty standard in ticketing systems.
My thoughts are that opaque things should not be seen by humans. The
subject line is certainly displayed by every mail tool that I have ever
seen.I think a better implementation of “not-for-human-consumption” data
might have been to use X-RT-* headers liberally.
This completely misses the point. When RT sends a user a message, the
user responds. The user’s response must include some key that lets RT
know what ticket they’re taking about. The only thing preserved by the
user’s MUA is the subject. (I guess rt could have gone with a key in
the sender, but there are just as many reasons not to do that)
seph
I’ll agree it’s a little ugly, but I don’t find it broken. It’s also
pretty standard in ticketing systems.
True.
The more I think about it the more I realize that you have to have some
sort of state coming through. If the users’ MUA won’t keep the headers
as needed, then something has to be done. Maybe text tags in the body
of the email? But what user is going to do that? 
The reason I was churning on this is because I have to get this working
with [company1] and [company2] subject lines, or figure out multiple
installs (Jesse’s post about mod_rewrite and mod_proxy was great), or
install and maintain multiple RTs and machines. I am just happy that
Debian has it right with “apt-get install request-tracker3”
rob
The reason I was churning on this is because I have to get this working
with [company1] and [company2] subject lines, or figure out multiple
installs (Jesse’s post about mod_rewrite and mod_proxy was great), or
install and maintain multiple RTs and machines.
I’d do multiple installs. fastcgi should be useful here.
I’ve thought about how to make rt scale to a hosting environment,
something that effectively runs N RT installs with one set of code,
but it’d be a lot of kinda pointless patching and no one’s paying me.
seph
Matthias Leisi wrote:
As those header almost certainly won’t make it back to RT once they have
been sent to the user, it may be better to have (unique|opaque)
identifiers coded into a mail address, e.g.From: +@
RT already provides hooks for this functionality, via the
“–extension ticket” args to rt-mailgate.
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
Rob Walker wrote:
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.This could be worked around with [sitename . queuename .
#.ticketnumber].
That’s certainly possible, although RT has no use for
the queuename there – it’d be cosmetic only…
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
Rob Walker wrote:
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.This could be worked around with [sitename . queuename .
#.ticketnumber].That’s certainly possible, although RT has no use for
the queuename there – it’d be cosmetic only…
I think that this is the point, for the end-user to see something which
is more aligned with the queue which they are using.
Also, for the ASP model, multiple queues/company names would help run
multiple instances on one install.
rob
Rob Walker wrote:
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.This could be worked around with [sitename . queuename .
#.ticketnumber].That’s certainly possible, although RT has no use for
the queuename there – it’d be cosmetic only…I think that this is the point, for the end-user to see something which
is more aligned with the queue which they are using.
You could always begin your ticket templates with:
Also, for the ASP model, multiple queues/company names would help run
multiple instances on one install.
If you’re selling RT as a revenue-generating service and need new
functionality, you should definitely have a word with us off-list.
Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.
-----BEGIN PGP SIGNED MESSAGE-----
On 04-Sep-2003, Jesse Vincent wrote message “Re: [rt-users] Subject-Tag per
Queue?”> On Wed, Sep 03, 2003 at 09:45:49PM -0700, Rob Walker wrote:
On Wed, 2003-09-03 at 19:33, Phil Homewood wrote:
Rob Walker wrote:
You’ll break the mailgate, as it looks for $rtname, not queue names.
Also, you risk that your tags may become non-unique, since another RT
instance might use the same queue names.This could be worked around with [sitename . queuename .
#.ticketnumber].That’s certainly possible, although RT has no use for
the queuename there – it’d be cosmetic only…I think that this is the point, for the end-user to see something which
is more aligned with the queue which they are using.You could always begin your ticket templates with:
Subject: ({ $Ticket->QueueObj->Name}) ($Transaction->Subject)
I tried doing this, but I noticed there is a global queue taking precedence for
the On Create scrip.
Is there a way to make a queue specific scrip override a global?
Andy Harrison
Great Works Internet
System Operations
(full headers for details)
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8
iQCVAwUBP42uxFPEkLgodAWVAQHiXAP+M4uV06xICWjQKiRgfLoaZSuCkcuZf8GC
36lIqeaCMUF1KXy2cWYc6X6qhWkAxYEa8l+eLkTfAy3JLS9euc5v/1C1pXaBeAfc
WPBiXyEY3rak3zPatT/KSVTjoiVe6lXUzE7CojPszQXZrOxFw85KI/OGWBp1zyZB
TrVaXdp4PQc=
=t3zS
-----END PGP SIGNATURE-----