My current favorite best-practice for RT extensions ( Announce: per-queue branding for RT)

RT Developers
1

We recently developed this RT extension. I’m somewhat more pleased with
how the library extensions worked out here than with things we’ve done
in the past. Additionally, it makes it a lot easier to install multiple
extensions than overloading the _Local mechanism.

Jesse

----- Forwarded message from Jesse Vincent jesse@bestpractical.com -----Date: Mon, 20 Mar 2006 12:04:51 -0500
From: Jesse Vincent jesse@bestpractical.com
To: rt-users@lists.bestpractical.com
Subject: Announce: per-queue branding for RT

I’m pleased to announce that it’s now possible to “brand”
the outgoing mail for each queue in your RT instance separately
using a new RT extension that works on RT 3.2 and RT 3.4.

You can download this extension from:

From the README:

This extension for RT 3.2 and 3.4 allows sites to “Brand” individual queues
with distinct tokens in the Subject: headers of outgoing email messages.

To enable this extension:

cd into the unpacked distribution directory

perl Makefile.PL
make
make install

edit your RT_SiteConfig.pm library to add the following line

immediately before the last line of the file:

use RT::Extension::BrandedQueues;

The only thing after that use …" line should be the line:

1;

You’ll also need to modify any of your local email templates which use
the $rtname variable. To edit your templates, log into RT as your
administrative user, then click:

Configuration → Global → Templates →

For example, RT’s default “Autoreply” includes this line:

“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{$rtname} #{$Ticket->id()}].”

Change this line to read:

“There is no need to reply to this message right now. Your ticket has been
assigned an ID of [{$Ticket->QueueObj->Tag} #{$Ticket->id()}].”

----- End forwarded message -----

2

We recently developed this RT extension. I’m somewhat more pleased with
how the library extensions worked out here than with things we’ve done
in the past. Additionally, it makes it a lot easier to install multiple
extensions than overloading the _Local mechanism.

Jesse,

Looking at the code, I would summarize the new best practice as:

  • Introduce HTML using Callbacks and components in $RTHOME/local/html
  • Introduce libs in the RT::Extension namespace in $RTHOME/local/lib
    and use the module from RT_SiteConfig.pm.

Did I miss anything?

Why even install the libs in $RTHOME and not just the perl site
lib? Just because it is of no use without RT?

Thanks for the great new extension!

-Todd

3

We recently developed this RT extension. I’m somewhat more pleased with
how the library extensions worked out here than with things we’ve done
in the past. Additionally, it makes it a lot easier to install multiple
extensions than overloading the _Local mechanism.

Jesse,

Looking at the code, I would summarize the new best practice as:

  • Introduce HTML using Callbacks and components in $RTHOME/local/html
  • Introduce libs in the RT::Extension namespace in $RTHOME/local/lib
    and use the module from RT_SiteConfig.pm.

Did I miss anything?

It’s more about declaring extensions that are in RT::Core::Module
namespaces inside your extensions’s lib file.

Why even install the libs in $RTHOME and not just the perl site
lib? Just because it is of no use without RT?

Because then you hurt yourself when you have a second RT instance.

4

We recently developed this RT extension. I’m somewhat more pleased with
how the library extensions worked out here than with things we’ve done
in the past. Additionally, it makes it a lot easier to install multiple
extensions than overloading the _Local mechanism.

Jesse,

Looking at the code, I would summarize the new best practice as:

  • Introduce HTML using Callbacks and components in $RTHOME/local/html
  • Introduce libs in the RT::Extension namespace in $RTHOME/local/lib
    and use the module from RT_SiteConfig.pm.

Did I miss anything?

It’s more about declaring extensions that are in RT::Core::Module
namespaces inside your extensions’s lib file.

Why do that? If you remove the declaration you don’t really get
the benefit of disabling the extension because all the componentes
(especially callbacks) are in place. Wouldn’t it be better to use
of the the pluggable modules to auto-require the install extensions?

Just wondering…

5

We recently developed this RT extension. I’m somewhat more pleased with
how the library extensions worked out here than with things we’ve done
in the past. Additionally, it makes it a lot easier to install multiple
extensions than overloading the _Local mechanism.

Jesse,

Looking at the code, I would summarize the new best practice as:

  • Introduce HTML using Callbacks and components in $RTHOME/local/html
  • Introduce libs in the RT::Extension namespace in $RTHOME/local/lib
    and use the module from RT_SiteConfig.pm.

Did I miss anything?

It’s more about declaring extensions that are in RT::Core::Module
namespaces inside your extensions’s lib file.

Why do that? If you remove the declaration you don’t really get
the benefit of disabling the extension because all the componentes
(especially callbacks) are in place. Wouldn’t it be better to use
of the the pluggable modules to auto-require the install extensions?

Just wondering…

Why even install the libs in $RTHOME and not just the perl site
lib? Just because it is of no use without RT?

Because then you hurt yourself when you have a second RT instance.

Thanks for the great new extension!

-Todd

Jesse,

What do yo think about the plugable idea?

6

It’s more about declaring extensions that are in RT::Core::Module
namespaces inside your extensions’s lib file.

Why do that? If you remove the declaration you don’t really get
the benefit of disabling the extension because all the componentes
(especially callbacks) are in place. Wouldn’t it be better to use
of the the pluggable modules to auto-require the install extensions?

That’s somewhat unrelated. I’m talking about keeping extensions’
RT core module overlays bundled together. Using the various “plugin”
systems on CPAN would currently lose you the ability to order which
things are loaded first, which can sometimes be a concern.