Managing global options on a per queue basis

Hi, one of the features requested on our installation of RT has been to be
able to manage some global options, like ParseNewMessageForTicketCcs, on a
per-queue basis. Controlling this behaviour had to be done via the GUI,
with the option of enabling or disabling the facility in RT_Site Config.pm.

Another one of the requests was to enable parsing emails to thread replies
to existing tickets when the subject failed to match but the message id
matched an existing ticket. I found
http://rt3.fsck.com/Ticket/Display.html?id=6704 and used the code there as
a basis for this functionality.

I found the basis for the GUI changes on the wiki somewhere, but I can’t
find it again, so I haven’t be able to give kudos for the original author :frowning:

The DB performance for handling MessageId was not very good, adding an
INDEX made a world of difference.

You have to set PerQueueGlobals to 1 in RT_SiteConfig.pm else the per
queue code is never executed.

InReplyTo has been setup to allow it to be set globally or per queue.

A check box is added to the Queue Admin page for each of the global
options being handled per queue.

I’ve tested these changes on a stage machine and it all seems to work
well. I’m currently looking in to how to write tests for this to allow
more robust testing.

I’d appreciate any feed back on this code and suggestions on ways it could
be improved.

Cheers, Jeff.

Jeff Fearn jfearn@redhat.com
Software Engineer
Engineering Operations
Red Hat, Inc

RH-PerQueue.patch (10.1 KB)

LoadByMessageId looks in-efficient. You better start from Transactions
and join Attachments and don’t join tickets at all. Just limit
ObjectType to ‘RT::Ticket’ in txns table. Using this you can order by
ObjectId right in SQL and don’t do this in perl.

Took another look and think it’s even better to add a method in
RT::Tickets that finds tickets by message id (may be it even there)
and your method may look like:

sub LoadByMessageId {

my $tickets = RT::Tickets->new( $self->CurrentUser );
$tickets->LimitByMessageId( $mid );
$tickets->OrderBy( ‘id’ );
my $first = $tickets->First;
return $self->Load( $first? $first->id : 0 );
}

Something like that (pseudo-code).

Also, it’s really not good idea to violate ACLs in this function and
use RT::SystemUser. May be it looks right, however it’s not good
option. Users of this method should decide whether they want any
tickets or only those the current user can see. So my $Attachs =
RT::Attachments->new($RT::SystemUser); should be my $Attachs =
RT::Attachments->new( $self->CurrentUser );.

Regarding attributes, you can find code in RT that do this already and
it’s better to wipe out attribute when it’s set to false value to
avoid table growing. This code may need generalization and get/set
methods can even be auto-generated like we do for standard
getters/setters.

That’s it. I think we can partly merge it into RT.On Tue, May 5, 2009 at 8:20 AM, Jeff Fearn jfearn@redhat.com wrote:

Hi, one of the features requested on our installation of RT has been to be
able to manage some global options, like ParseNewMessageForTicketCcs, on a
per-queue basis. Controlling this behaviour had to be done via the GUI,
with the option of enabling or disabling the facility in RT_Site Config.pm.

Another one of the requests was to enable parsing emails to thread replies
to existing tickets when the subject failed to match but the message id
matched an existing ticket. I found
http://rt3.fsck.com/Ticket/Display.html?id=6704 and used the code there as
a basis for this functionality.

I found the basis for the GUI changes on the wiki somewhere, but I can’t
find it again, so I haven’t be able to give kudos for the original author :frowning:

The DB performance for handling MessageId was not very good, adding an
INDEX made a world of difference.

You have to set PerQueueGlobals to 1 in RT_SiteConfig.pm else the per
queue code is never executed.

InReplyTo has been setup to allow it to be set globally or per queue.

A check box is added to the Queue Admin page for each of the global
options being handled per queue.

I’ve tested these changes on a stage machine and it all seems to work
well. I’m currently looking in to how to write tests for this to allow
more robust testing.

I’d appreciate any feed back on this code and suggestions on ways it could
be improved.

Cheers, Jeff.


Jeff Fearn jfearn@redhat.com
Software Engineer
Engineering Operations
Red Hat, Inc


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Best regards, Ruslan.