[rt-users] Customization Advice

[Bruce Campbell]

On Wed, 6 Mar 2002, Smylers wrote:

>   * 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.

Quite literally, you can do anything in a ScripAction.  You can do
anything to merging tickets to commanding a coffee machine to brew a fresh
pot when certain content is matched.

You are limited in the RT objects that you can immediately access, but a
little bit of poking around usually reveals the Right Way in which to do
something.

>   * 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?

Most of the contributed ScripConditions/ScripActions are supplied with an
'insert' script, where running it will perform the background SQL magic
for you.  It is easier (and safer) for you to copy one of these and change
as appropriate, than to be messing about with SQL INSERT statements.

>   * 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.

Yes, its a stupid idea and you should never be allowed out in public.  So
there.

Actually, the main issue against multiple queues is the administration
overhead involved in creating and maintaining the queues.  Personally I
think that a model of one queue per document is an administrative
nightmare waiting to happen, however if you think that the overhead is
worth it, by all means go ahead.

I would suggest modifying the queue listing tabs in the web interface to
cut down on the extra clutter though.

>   * 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 NotifyAdminCcs
>
>     That 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?

Caution: If a ticket comes in, and the 'owner' remains Nobody, then it is
up to the AdminCcs (a possibly much smaller, and busy group of people) to
notice this.  I would suggest in addition:

	OnCorrespondOnUnOwned NotifyCcs
	OnCommentOnUnOwned NotifyCcs

>   * 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?

You can change the web pages for this.  See rt-users in January for
details.  ( You want to change the Admin tabs to check the $CurrentUser
rights before letting them display pages in /Admin/ )

>   * 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?

Sure, you can do anything ;)

>   * 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?

urm?

Possibly the best would be to have the fax interface submit the fax (MIME
message) as a ticket comment (via email).  Identifying which ticket the
fax belows to is left as an exercise for the reader.  Let RT's mailgate
put the gif into the attachments table, don't reinvent the wheel ;)

>   * 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?

Two solutions:

	a) Use ticket relationships to essentially have two tickets for
	   each issue, one an 'overseer' and 'worker'.  Creating these and
	   maintaining it is your problem ;)
or
	b) OnSetKeywordDeliverer AddPersonAsWatcher with template blank
	   OnSetKeywordDeliverer NotifyPerson with template YourTicketNow

>   * 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).
>
>     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.

Paraphrasing Robert J. McCloskey, I know that you believe you understand
what I think that you said, but I am not sure you realise that what you
said is not what the rest of us understood.

If you shifted the standard RT::Action::SendEmail elsewhere and created
your own RT::Action::SendEmail to override SetSubject (etc), and then
include RT::Action::SendEmail_Install, you'd be laughing.

This means that there is no need to update any references pointing to
RT::Action::SendEmail, and any future updates to RT::Action::SendEmail (as
RT::Action::SendEmail_Install of course) with the exception of SetSubject
(etc) are magically incorporated in your code.

Regards,

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations