Site-specific customization of RT, and DTRT

RT Users
1

Hi Folks!

I’ve been following some traffic on the list, and I’m wondering about how to
best customize RT to meet the needs. I’ve seen some traffic lately about
the rt/local/ directory, and I’m wondering how it fits into the greater
scheme of things. This is a bit long, so I hope you bear with me!

What I’ve done with my site (which is relatively new) is use a modified
autohandler for LDAP and use the LDAPsync script (Big Thanks go out to Mike
Quintero and Johan Edstrom for all their help with that.)

I’ve modified the rt/WebRT/html/Elements/Headers and I’ve modified the
rt/WebRT/html/Elements/Self/Service/Elements/Headers to remove the prefs
link (since I don’t want users thinking they can change their passwd, and
sigs aren’t essential).

I’ve modified the rt/WebRT/html/Elements/Tabs to put in [Help] (which I have
yet to write), [Reports], and the [Quick Ticket] (LDAP search).

I’m looking at putting in stuff like the StockAnswers, and DTRT (once I
figure out how to install it - what goes where???). I like the idea behind
DTRT, but I haven’t had time to install it, and I’m reluctant to experiment
too much on what is now a production system.

What I’m asking is: Is what I’ve currently done the best way to do it? I’m
thinking down the lines when it comes time to upgrade… and upgrade… and
upgrade… I don’t want my customizations to get wiped out at some point in
the future, requiring a lot of work to fix it. The rt2.0.11 → rt2.0.12 was
fairly painless, in that none of my tweaks got destroyed. Am I going about
things the right way, or is there a better way to do it?

Thanks in advance!

Michael K. Brown
Lab Technician
ATM Engineering Services - Lab Services
Tel: (613) 784-4354
michael.k.brown@alcatel.com

2

Michael K Brown wrote:

I’ve seen some traffic lately about the rt/local/ directory, and I’m
wondering how it fits into the greater scheme of things.

‘RT’ has files stored under these directories:

rt/WebRT/html/
rt/lib/

Stuff under those directories will change on upgrades.

You can put things under these directories:

rt/local/WebRT/html/
rt/local/lib/

If a file of the same name exists in the local and non-local
directories, the local one will be used.

So for example I wanted single-value keyword selects to be drop-down
lists (rather than the big scrolling list thingies they are by default).
So I copied this file:

rt/WebRT/html/Ticket/Elements/EditKeywordSelects

into this one:

rt/local/WebRT/html/Ticket/Elements/EditKeywordSelects

then edited that one. ‘RT’ automatically uses the localized one, which
is left alone by any upgrades.

Smylers
GBdirect

3

Michael K Brown wrote:

What I’m asking is: Is what I’ve currently done the best way to do it? I’m
thinking down the lines when it comes time to upgrade… and upgrade… and
upgrade… I don’t want my customizations to get wiped out at some point in
the future, requiring a lot of work to fix it. The rt2.0.11 → rt2.0.12 was
fairly painless, in that none of my tweaks got destroyed. Am I going about
things the right way, or is there a better way to do it?

My way takes a bit of setup, but it’s been worth it. :slight_smile:

I keep a local CVS repository, including my changes, and periodically
import later versions from Jesse’s tarballs. A simple merge and all
my changes are incorporated into the new version.

Using the Mason “local” directories is fine, but when you end up
duplicating more than a couple of files, it becomes less fun; you
still need to ensure your “local” files don’t become stale. CVS
helps take care of this for you.

4

You can put things under these directories:

rt/local/WebRT/html/
rt/local/lib/

If a file of the same name exists in the local and non-local
directories, the local one will be used.

That was my understanding of the purpose of rt/local/, but appears not
to be the case. It works for html/, but not lib/.

I’ve easily made it work for lib by editing each of the files in rt/bin
from having these two lines:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/etc”;

to these three:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/local/lib”;
use lib “/usr/local/rt/etc”;

That’s fine. But the fact that I had to do this hacking means that it
isn’t how things are supposed to be done, and suggests that I’ve greatly
misunderstood the purpose of rt/local/.

  • Should I just be putting customized modules under rt/lib/RT, along
    with the standard ones?

  • What should be in rt/local/ then? If rt/local/lib/ isn’t the done
    thing then the only content of that directory is rt/local/WebRT/,
    and the only content of that directory is rt/local/WebRT/html/,
    and I don’t see the point of having two extra levels of hierarchy
    that don’t contain anything.

What am I missing here?

Smylers
GBdirect

5

Hi folks.

I hope I can be helpful here; it took me a long time to figure out
how Mason does things, and where/when the local component root is
used. Granted, it’s been a few years since I’ve seriously looked
at the internals of HTML::Mason, but this should all still be
fairly accurate.

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

You can put things under these directories:

rt/local/WebRT/html/
rt/local/lib/

If a file of the same name exists in the local and non-local
directories, the local one will be used.

That was my understanding of the purpose of rt/local/, but
appears not to be the case. It works for html/, but not lib/.

That’s because the local thing is for HTML::Mason’s component
root only, and has nothing to do with perl. See below for a more
detailed explanation.

I’ve easily made it work for lib by editing each of the files
in rt/bin from having these two lines:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/etc”;

to these three:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/local/lib”;
use lib “/usr/local/rt/etc”;

This will work, although for completely different reasons than
the reasons that local works for html files and Mason components.

  • What should be in rt/local/ then? If rt/local/lib/ isn’t the done
    thing then the only content of that directory is rt/local/WebRT/,
    and the only content of that directory is rt/local/WebRT/html/,
    and I don’t see the point of having two extra levels of hierarchy
    that don’t contain anything.

Note that the way HTML::Mason works is that components will be
looked for in local, not HTML files called by Apache. (A
component in Mason-speak is anything that is invoked using the
<& &> syntax.)

Here’s an abbreviated look at how HTML pages are served through
HTML::Mason: The browser requests a URI, Apache turns it into a
path on the system, and then Apache passes control to
HTML::Mason (in the form of the RT::Mason package, which is
defined in your webmux.pl script), which parses/executes that
file. During the execution of that file, HTML::Mason quite often
has to look in other places on the filesystem for components;
this is where local comes in. HTML::Mason will look in the local
hierarchy for things it includes.

There are some fudges in there; HTML::Mason has things called
autohandlers and dhandlers, which can take over at various spots
in the parsing/execution stage, and which are HTML::Mason
specific.

So why does the second “use lib” line above work? Because it’s
telling perl, not HTML::Mason, where to look for perl modules.
If you have a Mason component that loads My::RT::Module, perl’s
lib path is searched, not Mason’s component root.

Clear? Not clear enough?

(darren)

Doubt isn’t the opposite of faith; it is an element of faith.
– Paul Tillich, German theologian.

6

darren chamberlain wrote:

I hope I can be helpful here;

Ta.

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

That was my understanding of the purpose of rt/local/, but
appears not to be the case. It works for html/, but not lib/.

That’s because the local thing is for HTML::Mason’s component root
only, and has nothing to do with perl.

perldoc HTML::Mason::Interp suggests that HTML::Mason can take multiple
alternative component roots. The fact that it’s called “local” is an
‘RT’ thing rather than being hardcoded into Mason.

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/local/lib”;
use lib “/usr/local/rt/etc”;

This will work, although for completely different reasons than
the reasons that local works for html files and Mason components.

Yeah.

  • What should be in rt/local/ then? If rt/local/lib/ isn’t the done
    thing then the only content of that directory is rt/local/WebRT/,
    and the only content of that directory is rt/local/WebRT/html/,
    and I don’t see the point of having two extra levels of hierarchy
    that don’t contain anything.

Note that the way HTML::Mason works is that components will be
looked for in local, not HTML files called by Apache.

Yup. But since Mason doesn’t do this by itself, it means somebody
specifically designed ‘RT’ with the rt/local/ in mind. I’m trying to
work out what they had in mind.

config.pm has these two settings:

$MasonComponentRoot = “/usr/local/rt/WebRT/html”;
$MasonLocalComponentRoot = “/usr/local/rt/local/WebRT/html”;

Why did somebody decide to make that second one what it is, and not,
say:

$MasonLocalComponentRoot = “/usr/local/rt/local”;

The logical conclusion is that there’s something else which can go under
rt/local/ other than rt/local/local/WebRT/html/. That’s why I then
tried putting libraries there, since it made sense.

Here’s an abbreviated look at how HTML pages are served through
HTML::Mason: The browser requests a URI, Apache turns it into a
path on the system, and then Apache passes control to
HTML::Mason …

That’s what I was assuming. Although there’s something going on which
makes Mason only do this for some types of files – do you know how to
make it try to grab images locally as well:

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

So why does the second “use lib” line above work? Because it’s
telling perl, not HTML::Mason, where to look for perl modules.
If you have a Mason component that loads My::RT::Module, perl’s
lib path is searched, not Mason’s component root.

I follow why it works. It seemed to me to be nicely symmetrical to
make the two different paths work like that, which is how I initially
mis-interpreted ‘RT’ as being. When I saw that it wasn’t, it was
trivial to make it so.

My mis-understanding is conceptual rather than technical – why is
rt/local/ like it is, and how does ‘RT’ envisage that it should be used?

Thanks very much for your time on this.

Smylers
GBdirect

7

Short version: the design of rt/local anticipates future functionality.
Where yes, it’ll be easy to drop your own modules in rt/local/lib/RT.
(And I’ve got a couple tricks up my sleeve that will make that even easier
and more powerful)

-jOn Tue, Mar 26, 2002 at 03:06:49PM +0000, Smylers wrote:

On Friday I wrote:

You can put things under these directories:

rt/local/WebRT/html/
rt/local/lib/

If a file of the same name exists in the local and non-local
directories, the local one will be used.

That was my understanding of the purpose of rt/local/, but appears not
to be the case. It works for html/, but not lib/.

I’ve easily made it work for lib by editing each of the files in rt/bin
from having these two lines:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/etc”;

to these three:

use lib “/usr/local/rt/lib”;
use lib “/usr/local/rt/local/lib”;
use lib “/usr/local/rt/etc”;

That’s fine. But the fact that I had to do this hacking means that it
isn’t how things are supposed to be done, and suggests that I’ve greatly
misunderstood the purpose of rt/local/.

  • Should I just be putting customized modules under rt/lib/RT, along
    with the standard ones?

  • What should be in rt/local/ then? If rt/local/lib/ isn’t the done
    thing then the only content of that directory is rt/local/WebRT/,
    and the only content of that directory is rt/local/WebRT/html/,
    and I don’t see the point of having two extra levels of hierarchy
    that don’t contain anything.

What am I missing here?

Smylers

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

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

8

Yesterday Jesse Vincent wrote:

Short version: the design of rt/local anticipates future
functionality.

Excellent – anticipating future functionality is one of my favourite
hobbies!

Where yes, it’ll be easy to drop your own modules in rt/local/lib/RT.

That sounds good. To get this to work, I only had to add an extra use
lib in rt/bin/*. To make this work for people in general I reckon the
only place needing changing is the Makefile. A quick test of replacing
the two occurrences of:

s’!!RT_LIB_PATH!!'$(RT_LIB_PATH)'g;"\

with:

s’!!RT_LIB_PATH!!'$(RT_PATH)/local/lib", "$(RT_LIB_PATH)'g;"\

seems to work for me. Something using another Makefile variable or two to do
that less hackily wouldn’t be too much more work.

(And I’ve got a couple tricks up my sleeve that will make that even
easier and more powerful)

I was going to offer to do the above properly and submit a patch to
rt-devel, if you’d like. But if you’ve already got a Cunning Plan and
would rather I just waited, then I’ll stop interfering …

Smylers
GBdirect