Customization Advice

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/

Quoting Smylers smylers@gbdirect.co.uk [Mar 06, 2002 12:26]:

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

Take a look at http://www.fsck.com/pub/rt/contrib/2.0/AutoAssign.pm.

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

If you do this, and use CVS to manage your documents, you should
look into the CVS commit handler at
http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/rt-commit-handler.

  • 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:

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

No comment other than that I like this idea a lot.

It look like you have a lot of fun ahead. Good luck!

(darren)

Competition is a by-product of productive work, not its goal. A
creative man is motivated by the desire to achieve, not by the
desire to beat others.
– Ayn Rand

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.

You might like to read through http://www.fsck.com/rtfm/ , various files
in http://www.fsck.com/pub/rt/contrib , and the Mailing lists linked from
http://www.fsck.com/ .

A lot of the ideas have been previously brought up, and some have been
implemented :wink:

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations
  • 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 :wink:

  • 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 :wink:

  • 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

Apologies for the delay in responding to the advice offered a few weeks’
ago – for some reason my boss seems to prefer me going out and earning
money rather than configuring our internal systems, and I’ve only just
got round to looking at this again.

Quoting Smylers smylers@gbdirect.co.uk [Mar 06, 2002 12:26]:

  • … when an e-mail response is sent to a new ticket it
    automatically becomes open and owned by the responder.

Take a look at http://www.fsck.com/pub/rt/contrib/2.0/AutoAssign.pm.

Ta. That’s looks like something I could use as basis for what I suspect
we want.

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 you do this, and use CVS to manage your documents, you should
look into the CVS commit handler at
http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/rt-commit-handler.

Yeah, that looks nice. I fear that we won’t actually be disciplined to
make use of it. I think with that and my ‘auto-own’ idea above, we’ll
initially run without them. Then we’ll see which repetative tasks are
irritating people and automate those.

  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

No comment other than that I like this idea a lot.

If I get something that works and doesn’t appear to be of use only to
us, I’ll make it available somewhere.

It look like you have a lot of fun ahead. Good luck!

Cheers.

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

  • 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 :wink:

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 :wink:

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 :wink:

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/

Earlier in the month I asked about putting tags at the end of subjects,
as I reckoned people would find them less intrusive there than at the
beginning, and attempted to outline how I thought this could work (which
led to Bruce Campbell’s Robert J McCloskey paraphrase …).

I wanted to achieve this in a way such that ‘RT’ can be upgraded and
provide a new version of RT::Action::SendEmail and I’ll automatically
get all the new features, without having to patch each upgrade
separately.

Anyway, I’ve now done this and got it working. It could actually be
done slightly more simply than my previous suggestion (and more
correctly too, in the general case). In case anybody else is interested
in this – or in overriding particular methods of RT::Action::SendEmail
for some other purpose – here’s the steps:

First create a new module in lib/RT/Action/TagAtEnd.pm consisting of
just these lines:

package RT::Action::TagAtEnd;

sub SetSubjectToken {
my $self=shift;
my $tag = “[$RT::rtname #”.$self->TicketObj->id."]";
my $sub = $self->TemplateObj->MIMEObj->head->get(‘Subject’);
unless ($sub =~ /\Q$tag\E/) {
$sub =~ s/(\r\n|\n|\s)/ /gi;
chomp $sub;
$self->TemplateObj->MIMEObj->head->replace(‘Subject’, “$sub $tag”);
}
}

1;

Note that that sub is taken in its entirety from RT::Action::SendEmail,
but “$tag $sub” have been swapped. (That’s the bit that puts the tag in
the subject.)

Then create another new module in lib/RT/Action/NotifyTagAtEnd. This
one is just three lines long:

package RT::Action::NotifyTagAtEnd;
use base qw(RT::Action::TagAtEnd RT::Action::Notify);
1;

What that’s saying is to base RT::Action::NotifyTagAtEnd on
RT::Action::TagAtEnd and RT::Action::Notify. Because of the way
Perl’s multiple inheritence rules work, that basically means that
whenever a method gets called on an RT::Action::NotifyTagAtEnd object,
Perl will search in this order:

1 the module itself – there aren’t any methods here, so this’ll
always fail

2 RT::Action::TagAtEnd – the only method there is SetSubjectToken()

3 RT::Action::Notify – all of the original methods that actually do
useful things (this module inherits from RT::Action::SendEmail,
which provides the original SetSubjectToken(), which won’t now be
invoked).

So from nearly all points of view this new class is the same as
RT::Action::Notify, but one method has been overridden. This works –
even though RT::Action::TagAtEnd isn’t really a class (it doesn’t
provide a constructor or anything), it can still have methods inherited
from it in this way.

You’ll want lib/RT/Action/NotifyAsCommentTagAtEnd.pm as well:

package RT::Action::NotifyAsCommentTagAtEnd;
use base qw(RT::Action::TagAtEnd RT::Action::NotifyAsComment);
1;

Finally you need to make RT use these new modules instead of your own.
This SQL did it for me with ‘MySQL’ (concatenation may be different with
other DBMSes):

UPDATE ScripActions
SET ExecModule = Concat(ExecModule, ‘TagAtEnd’)
WHERE ExecModule like ‘Noitfy%’

(I’m sure this would be better with a .insert script, but I haven’t yet
got the hang of those. And anyway that worked.)

That took longer to explain than it did to do.

Cheers.

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

( sheesh, has it been that long since I’ve been in the office? )

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

Not really. Most of the insert scripts don’t create extra rt users or
groups, and simply ask for the next id-number in the
Scrip{Action,Condition} table to be assigned. It doesn’t re-create
existing Scrip components.

To add a new ScripAction does my .insertdata script have to have a list
of all the existing ScripActions?

Nope.

I’ve seen that the 'RT Hackers Guide’
has appeared since my original question. I’ll read through that before
trying anything.

I really need to work on that some more. My home machine has a copy of
all publically contributed addons (web site, mailing lists or references)
and it will probably take me another month to review/test most of the
contrib stuff, and sift through the mailing lists for gems of wisdom
(which is what I intend the RT Hackers Guide to be).

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 :wink:

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

Thats pretty much what that db column is there for.

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.

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

A future innovation (currently in devel) with RT is the possibility of
RT-code-as-distributed and RT-code-for-local-override at the RT::Library
level. Have a look at some mails from Jesse last month on rt-devel for
more information.

Note that as with any customisation of a public tool, you will need to be
careful that your modifications continue to work as intended after you
upgrade the base system.

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

( sheesh, has it been that long since I’ve been in the office? )

Looks like it – you’ve certainly been conspicuous in your absence from
this list. Hope you’ve been enjoying yourself.

Most of the contributed ScripConditions/ScripActions are supplied with an
‘insert’ script …

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?

Not really. Most of the insert scripts don’t create extra rt users or
groups, and simply ask for the next id-number in the
Scrip{Action,Condition} table to be assigned. It doesn’t re-create
existing Scrip components.

Ah, I think I was just unlucky in my choice of where to steal from.
AutoAssign.pm.insert data is not inconsiderably complicated (and still
looks to me to be creating superfluous things).
OwnerChange/insert_condition.pl is a fraction of the size and makes
sense.

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.

That involves having to rename SendEmail.pm as SendEmail_Install.pm
every time we do an upgrade.

I did eventually get round to implementing it in a way which just
overrides a single sub of RT::Action::SendEmail and doesn’t require any
renaming:

http://lists.fsck.com/pipermail/rt-users/2002-March/007420.html

A future innovation (currently in devel) with RT is the possibility of
RT-code-as-distributed and RT-code-for-local-override at the
RT::Library level.

Sounds good.

Have a look at some mails from Jesse last month on rt-devel for more
information.

Ta. (I get a distinct feeling that I ought to be subscribed to that
list too anyway. I get another feeling that my boss won’t want me
spending any more work time on lists and I’ll have to subscribe from
home …)

Note that as with any customisation of a public tool, you will need to
be careful that your modifications continue to work as intended after
you upgrade the base system.

Of course. But keeping the change as small as possible minimizes the
chance that that area will have changed differently in the upgrade,
hence my desire just to override one sub.

Good to see you back.

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