[Rt-devel] managing global options on a per queue basis

Ruslan Zakirov ruslan.zakirov at gmail.com
Tue May 5 10:15:09 EDT 2009

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

That's it. I think we can partly merge it into RT.

On Tue, May 5, 2009 at 8:20 AM, Jeff Fearn <jfearn at 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 :(
> 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 at redhat.com>
> Software Engineer
> Engineering Operations
> Red Hat, Inc
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Best regards, Ruslan.

More information about the Rt-devel mailing list