[rt-users] Customization Advice

[Smylers]

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

  * 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
http://www.gbdirect.co.uk/