Save time with Bulk Update

Have you ever needed to update several tickets at the same time? With Request Tracker’s Bulk Update feature, you can perform the same action on several tickets simultaneously.

Starting in the Query Builder, first create a search that finds the tickets you need to update. When you have search results that meet your criteria, select Bulk Update from the RT submenu.

You'll be sent to a Bulk Update page where you can select / deselect tickets from your search, and make changes like resolving multiple tickets, or updating various ticket metadata like priority, custom fields, and ticket starts and due dates.

Give bulk update a try today!

A Personal Approach To RT With Gmail

Request Tracker is open source ticket tracking software typically discussed as enterprise software used by various types of businesses and organizations. There are plenty of diverse examples of how large and small businesses use RT to manage everything from help desk requests to security incident response to software bug tracking. But at Best Practical, we also hear from users who deploy RT on a much smaller scale, sometimes only for an individual user.

Being the type of person who finds it thrilling to spin up a new Digital Ocean droplet and see what open source tool I can use for my own personal needs, I also decided to try running a personal RT for myself. I also happen to work for Best Practical Solutions, so I am always asking myself what the software I make is capable of.

RT And Email

RT is built off of email. Although strictly speaking email isn't necessary for tracking tickets, you could solely use the web UI with no email alerts or ticket creation from email, for my use case I wanted to incorporate my personal email with RT. Luckily I have my own domain name that I use for personal email.

In my experience most companies will provision many email accounts for their RT to use with addresses like “support@example.com” and “sales@example.com” for example. These would be two separate inboxes that when emailed would create a new ticket in RT queues “Support” or “Sales”. Simple!

If you're like me though you're not interested in paying for the Gmail subscription for every single RT queue you want to make (around $6 a month per email).

Email Aliasing To The Rescue

G Suite allows you to set aliases for your inbox, so for my case I only paid for the “craig@example.com” but now I can point many email aliases to my single inbox. For this example I created two aliases “craig-billing@example.com”, “craig-travel@example.com”, and “craigs-rubber-duck-collection@example.com”.

Setting Up Gmail To Work With RT

As part of the set-up described here, you need to enable “less secure apps” with your Gmail account in order to fetch mail from your inbox. Once things are set up, you can keep your Gmail inbox as your personal inbox and use it with RT. Realistically we do not want a ticket for every email that comes into our inbox, we only want a subset of these emails to be preserved on our pristine RT life tracker!

Luckily for us Google makes it simple to automatically separate the junk emails and the worth-saving-in-RT emails through tags and filters. First let's go and create a Gmail tag called “RT”. This is where we will put the emails that we want to have RT open a ticket for. We don't want to do this manually though, so we can create a new Gmail filter.

We want the filter to check for our two email aliases as the “To” parameter and if one of them is indeed the value for the “To” parameter, go ahead and add one of our Gmail tags “RT/Travel” or “RT/Billing”.

Now that Gmail is all set let's hop onto our RT server and set-up our email fetching.

Getmail And rt-mailgate

We will use Getmail to fetch out emails from our RT inbox and pipe them to RT.

Getmail parameters can be stored in a config file and I will put mine at "/opt/rt4/etc/getmailrc-travel" with the following content: (Note you need one file for each email alias)

[retriever]
    type      = SimpleIMAPSSLRetriever
    server    = imap.gmail.com
    username  = craig@mydomain.com
    password  = supersecret
    mailboxes = ("RT/Travel",)

[destination]
    type      = MDA_external
    path      = /opt/rt4/bin/rt-mailgate
    arguments = ("--url", "http://rt.mydomain.com", "--queue", "
Travel
", "--action", "correspond",)

[options]
    read_all = false
    delete = true
    message_log = /var/log/getmail.log

Now lets break down the important parts here:

mailboxes = ("RT/Travel",)

This line tells Getmail that we only want to check the “RT/Travel” mailbox. In our case since we are using Gmail it is the “RT/Travel” tags mailbox.

[destination]
type      = MDA_external
path      = /opt/rt4/bin/rt-mailgate
arguments = ("--url", "http://rt.mydomain.com", "--queue", "Travel", "--action", "correspond")

We use the MDA_external option and the rt-mailgate utility to send the email over to RT. There it will create a ticket or add to an existing ticket in the “Travel” queue.

Finally we can create a cron job for fetching our email regularly:

*/1 * * * * /usr/bin/getmail --rcfile /opt/rt4/etc/getmailrc-travel --rcfile /opt/rt4/etc/getmailrc-biling

Now we should all be set to track all the important things in our life!

The configuration described here works well for personal use, but there are some limitations that require changes to scale for business use. But if you’re thinking about setting up your own RT for personal use, it’s a simple way to automatically route some email to your RT life tracker.

Automatic Ticket Assignment with Request Tracker

It's important to always set the Owner on a ticket since if no one owns it, it won't get done. Some RT’s users take tickets as they come in or someone might be responsible for assigning tickets. But for a busy RT, wouldn't it be great to assign tickets automatically?

The AutomaticAssignment extension allows you to do exactly that. As you can see in the video below, this RT extension automatically sets the ticket Owner based on rules you configure. You can set a filter to define the list of possible owners and then a chooser which determines the method to use when assigning users from the pool of users. Get the extension today: (https://metacpan.org/pod/RT::Extension::AutomaticAssignment)

One default filter option allows you to set the list of potential owners to an RT group, making it easy to manage membership. The "Work Schedule" filter is a little more interesting. It allows users (or, perhaps, only their manager) to select which business hours they are available. Only users currently working when the ticket comes in are then considered for assignment.

One method for assigning tickets is the "Active Tickets" chooser, which sets the owner of the ticket to the user from the filter who has the least number of currently active tickets. The "Round Robin" chooser cycles through the available users list in sequence, giving each user a ticket as their turn comes up.

Automatic assignment is triggered by RT's scrips system, so you can activate rules per queue and select default conditions like "On Create" or define custom conditions like "On Correspond from Requestor."

As with many things in RT, the filters and choosers are designed to be extended in the future and we look forward to hearing new ideas for both.

RT 4.4.3 and RTIR 4.0.1 Released

Best Practical is happy to announce a new set of releases for RT and RTIR for both the 4.4 series and also the 4.2 series. Here is a full list of new versions now available:

•  RT 4.2.15
•  RTIR 3.2.1 (works with RT 4.2.15)
•  RT 4.4.3
•  RTIR 4.0.1 (works with RT 4.4.3)

These releases include a number of updates and fixes. Here are just a few of the more notable changes:

• In the Query Builder, you can now select Active and Inactive for status and it will include all statuses that match the one you select. This can save adding a list of different statuses to see "what tickets are being worked on?"
• In RT, the Owner dropdown menu automatically converts to an autocomplete text box when it reaches 50 users. This number can now be set via the configuration option DropdownMenuLimit so you can easily update it to continue to show the dropdown with larger numbers.
• For accessibility, we added a user preference to use the previous attachment upload interface on the update page rather than the new dropzone file uploader.
• On the update page, recipient checkbox issues are fixed. Previously users would observe checkboxes for recipients below the message box getting checked or unchecked unexpectedly. This happened because the page calls back to the RT server to process any changes you make on the page and sometimes the response could conflict with boxes you may have checked. We've tried several different fixes and included the one that worked best. You'll now see the page is grayed out until the response from the server is processed so you know not to try modifying things while it's still running.

As always, you can view the full set of changes in our release notes. You can also view them on github using the details noted at the bottom of the release notes.

Instructions for updating RT and RTIR are provided in the README files for each release. Always make sure you have good database and file backups before upgrading. Contact Best Practical at sales@bestpractical.com if you need professional assistance with upgrading from any previous versions of RT or RTIR.