New module Path::Iterator::Rule::RT

I use Request Tracker (RT) all the time for work and home projects. What this means is I am left with ticket litter--lots of directories with names like test, examples, ETL, Proof of Concepts, foo, bar, baz, x. It all adds up to lots of ticket litter. Now I have a ticket for everything I do. (More on that later.)

That left me with a new problem. I had directories full of ticket numbers. It became overwhelming, and I needed a solution.

And so was born Path::Iterator::Rule::RT.

Using two packages from CPAN this was easy work.
Path::Iterator::Rule
RT::Client::REST

Path::Iterator::Rule is extendable with custom rule subroutines. Using this with RT::Client::REST made it very easy to add RT ticket information into a rule to select directories.

Here are some examples using Path::Iterator::Rule::RT.

# This will print all tickets in the directory that have resolved tickets.

use Path::Iterator::Rule;
use Path::Iterator::Rule::RT;
my $rule = Path::Iterator::Rule->new;
$rule->status("resolved");
for my $file ( $rule->all(@ARGV) ) {
say $file;
}


This will print all tickets in the directory that have tickets in the General queue that were created yesterday. This is slightly tricky. The TicketSQL is not as it appears. It has id=directory name added to it.

So this
$rule->TicketSQL("Queue='General' AND Created = 'yesterday'");
becomes
"id=directory name AND Queue='General' AND Created = 'yesterday'"

use Path::Iterator::Rule;
use Path::Iterator::Rule::RT;
my $rule = Path::Iterator::Rule->new;
$rule->TicketSQL("Queue='General' AND Created = 'yesterday'");
for my $file ( $rule->all(@ARGV) ) {
say $file;
}

3 Comments

I have an emacs lisp function that takes a ticket number and creates a directory for the ticket. Another function interprets a number (the directory name in dired mode) as a ticket and opens the browser on that ticket. The edit-server chrome plugin means I edit most of my ticket messages in emacs too. Yesterday I started poking around the RT REST interface with the request.el library and a view to making it all a bit more seamless.

This module could come in quite handy to that end. Thanks!

I'm working in a group that uses everyone else's ticket system but does not use one of our own for our work. Coming from environments where the ticket is king, I've found this way of working very strange. I have attempted to stop gap with things like ToDo lists in wiki pages and so on.

Your post reminds me of why this is such a bad idea and why I want a ticketing system to do this with. Tools like Trac and Gitlab don't seem to integrate as well with the email-centric work flow I see around me.

I guess this is me finally admtting that I better get RT installed and start using it at least for my todo list, and probably try to get others in the group to do it too.

Thanks for reminding me that tools can make my life better.

Leave a comment

About Robert Blackwell

user-pic I am a Pittsburgh Perl Parent.