I’ve been playing with RT for a couple of weeks now (in odd snatches of
time that is, not continuously), I like it, and I want to get it set up
and running for us here. I’m beginning to get the hang of which things
are where and what it’s possible to do, and I seem to have had
reasonable success at merely guessing the Mason syntax.
What I’m really after is some kind of sanity-check from people who’ve
done this kind of thing before. Listed below are some of the things I’m
considering doing.
I’d appreciate any warnings people could offer if any of them sound like
not a good idea for whatever reason (me misunderstanding how a feature’s
supposed to be used; thinking I want something that would actually make
life harder; suggesting a solution that wouldn’t work; whatever …)
Apologies for its length. Responses to only some of these points are
still most welcome.
-
All the default scrip actions result in some sort of e-mail being
sent. Presumably it’s possible to have other sorts of actions? I
was thinking of things like, when an e-mail response is sent to a
new ticket it automatically becomes open and owned by the responder. -
I’ve found the table in the database where scrip actions are listed.
Presumably to add in new ones I just add a row here with the obvious
fields? -
The installation guide counsels against creating many queues,
especially those for transient projects. I think I want to ignore
this advice.One of the things we do is write and maintain various documents, and
I’d like to use RT for tracking document issues and enhancements
internally. If we use a single queue for all documents we could
have a keyword identifying which document it is. But then it’s hard
to initiate an issue by e-mail for a particular document. Also, it
seems to be more effort to have people just seeing requests relating
to documents in which they are interested.That’s why I think I want one queue per document (each with its own
e-mail address). Please let me know if this is stupid. -
For a given customer-facing queue, we’d like a new incoming request
to be circulated to a bunch of people (since we don’t know who’ll be
in that day, or who ought to deal with it). Once it’s been assigned
to somebody and they’re dealing with it, in general others don’t
need to know about it.Since we have no need for the Cc/AdminCc distinction (all staff who
are involved in something are allowed to change things) I was
thinking of making everybody involved be a Cc for the queue (and
nobody an AdminCc), then creating a NotifyCcs scrip and setting up:OnCreate NotifyCcs
OnCorrespond NotifyRequestor
OnCorrespond NotifyOwner
OnCorrespond NotifyAdminCcs
OnComment NotifyOwner
OnComment NotifyAdminCcsThat way, after the initial request has been sent to everybody, only
the Owner and anybody designated an AdminCc for that ticket gets
mailed. Is that sane? -
There are some queues in which we’d like external users to be able
to see what the state of their queue is. The self-service interface
may not be quite good enough for this – we’d like some users to be
able to view all tickets in a particular queue, not just ones they
requested.Creating a group for such external users and giving them just
SeeQueue and ShowTicket rights. This seems to work. Such an
external user doesn’t seem to be able to do any damage (insufficient
rights errors) but can peruse things such as the list of users and
their rights. Should this be of concern? -
I’m going to change the webpages quite a bit. At the moment there
are seven tabs for a ticket. I think that we want:1 The main tab similar to the current jumbo tab, that is with all
the common information but in an editable format.2 A history tab with all correspondence and comments on it.
3 A printer-friendly tab with just all the information, so that
printing just that page gives a hard copy of absolutely
everything known about that ticket. This should include contact
information for all requestors (assuming that it is in the RT
database).4 Other tab(s) with anything else not covered by the above.
Does anybody see a problem with that?
-
We currently have many contact details in a different database.
It’s possible that in time we may decide it’s more convenient for RT
to be our primary contact DB (especially since everybody who mails
us gets added automatically), but I’m not going to be able to
convince people of that before we’ve even started using the
software.Initially we’ll probably just have e-mail addresses in RT and leave
other contact details elsewhere. All contacts at the comment have
an ID, from which a URL on our intranet can be formed. To get links
from RT to external contact details, we’ll need to store this ID in
RT. I pondered mis-using the zip code field, then I noticed
ExternalContactInfoId in the DB, but can’t see anywhere to set this
in the gui. Can I create a textbox for setting this field, then
form links out of it? -
New faxes arrive as gifs on our intranet. It’s possible to attach a
fax to a ticket by saving the gif with a web-browser to the hard
disk, then uploading the same gif back from the disk through the
browser using the ‘Attach’ field of a new comment.I hope it’s obvious that this isn’t ideal. If I put an ‘Attach to
ticket number’ thing in our fax interface, then directly inserted
such faxes in the Attachments table from there, would that work?
Would I also need to create a transaction for each new attachment? -
For some tasks we have one person responsible for overseeing the
task and ensuring it gets done, and somebody else charged with
delivering the result to the client.The best way we’ve thought of arranging this is for the oversee-er
to be the ticket Owner, and the deliverer be set with a keyword.
This is slightly icky, in that in theory somebody could be assigned
to deliver a task by a keyword but not actually have been added as
an AdminCc and therefore know nothing about it! Can anybody think
of a better way? -
We’d prefer to have the ticket tag at the end of the subject line
(less intrusive to requestors) and not have “via RT” in the
addresses (it’s the kind of thing that could puzzle a requestor; our
users will be able to spot RT things anyway).To do this I could subclass RT::Action::SendEmail as
RT::Action::SendEmailGBdirect and override SetSubjectToken() and
SetReturnAddress(). Then I’d have to modify RT::Action::Notify (and
::Autoreply) to be ISA ::SendEmailGBdirect rather than ::SendEmail.It wouldn’t be great just to copy ::Notify into the local/ tree and
change that one @ISA line, since that means any future RT
improvements to that file would be completely ignored as my local
version is used instead.So would it work if I created RT::Action::NotifyGBdirect which ISA
qw<RT::Action::SendEmailGBdirect RT::Action::Notify> but has no
other content? If I understand Perl multiple inheritance correctly,
this would take SetSubjectToken() and SetReturnAddress() from
::SendEmailGBdirect and everything else from ::Notify, thereby doing
what I want and not clobbering future upgrades.
Thanks for wading through the above. Your guidance is appreciated.
Smylers
GBdirect
