[rt-users] Customization Advice

[Smylers]

On Mar 7 Bruce Campbell wrote:

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

Excellent.  We often have a problem with coffee-making round here --
maybe we should implement something which automatically assigns
coffee-making to the member of staff with the fewest other tickets
pending or something, repeated a few times a day ...

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

I'd had a look at these but found them very scary.  For example,
AutoAssign.pm.insertdata appears to run in package RT (as used by
RT.pm), then looks to be creating users and groups (that I'd expect
already to exist), then creates ScripActions (but all of them, the
existing ones plus the new ones), and the same for ScripConditions.  Is
that right?

To add a new ScripAction does my .insertdata script have to have a list
of all the existing ScripActions?  I've seen that the 'RT Hackers Guide'
has appeared since my original question.  I'll read through that before
trying anything.

> >   * The installation guide counsels against creating many queues,
> >     especially those for transient projects.  I think I want to ignore
> >     this advice.
>
> Actually, the main issue against multiple queues is the administration
> overhead involved in creating and maintaining the queues.

I think I can cope with that.  It'll only be a dozen or two queues in
total.

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

Yes.  In particular I'm aiming for something where each queue has its
own 'homepage'.  (I'll probably do something with mod_rewrite as well to
give each queue homepage a nice URL.)  When viewing a ticket there'll be
a link back to the list of all tickets in that queue.  Anywhere in a
queue there'll be a direct link to the config for that queue, and one
back from queue config to that queue.

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

That's a good idea.

> >     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/ )

Thanks.

> >     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 ;)

Well, obviously I _could_ do that!  I was asking to check that it's
sane, that is that 'RT' isn't internally using that field for something
that I'd break (and/or that there's some simpler way of doing this that
I've missed).

> >   * New faxes arrive as gifs on our intranet. ... 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?
>
> 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 ;)

I'd initially dismissed that as being excessive, since it would involve
our intranet server sending an e-mail from the fax system, which would
go via our mail server, back to the intranet server, and be fed into
another program on the same server it started on.  But considering what
you said, that doesn't really matter -- a few extra network packets is
nothing compared to the effort in re-inventing wheels!

I've now realized there's something somewhere between those two --
having the fax software pipe the mail directly into rt-mailgate.

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

That sounds like it's going to get out of control.

> 	b) OnSetKeywordDeliverer AddPersonAsWatcher with template blank
> 	   OnSetKeywordDeliverer NotifyPerson with template YourTicketNow

That's a good solution -- I hadn't considered having ScripConditions
that rely on particularly-named keywords.

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

What makes you think I could understand that?  I think a diagram might
help.

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

That involves having to rename SendEmail.pm as SendEmail_Install.pm
every time we do an upgrade.  There are too many other packages round
here which either require a list of GBdirect mods on upgrading or which
we simply don't upgrade any more.  I'm really impressed with the way
'RT' uses the /local/ directory to make local mods easy (and the use of
separate Elements and the like, to enable small independent mods).

I know that that's only renaming one file, but it only takes a few more
things like that and suddenly it's a chore.  I still reckon that my way
avoids this completely.  I'll give it a go.  If I can get it to work,
then I'll draw a diagram and post back here.  If I can't, then I'll
quietly forget I ever made this claim in the first place ...

Cheers.

Smylers
-- 
GBdirect
http://www.gbdirect.co.uk/