Join us for our Q2 Request Tracker training in Dallas!

Hello! Best Practical is pleased to announce our second Request Tracker training for 2014! We will be in Dallas, Texas on May 20-21. We do have a limit on how many people we can effectively teach, so please register as soon as you can to make sure you get a seat. If you can't make Dallas, we will have upcoming sessions later this year in Boston, MA and Los Angeles, CA. Please let us know if you have a suggestion for a future location by dropping us a line at training@bestpractical.com!

This training will introduce you to the new features in RT 4.2 as part of a comprehensive overview of RT. Whether you're an old hand at RT or a recent convert, you'll have a good understanding of all of RT's features and functionality by the end of the session.

The first day starts off with a tour of RT's web interface and continues with a detailed exploration and explanation of RT's functionality, aimed at non-programmer RT administrators. We'll walk through setting up a common helpdesk configuration, from rights management, constructing workflows and notifications, and the basics of Lifecycles.

The second day of training picks up with server-side RT administration and dives into what you need to safely customize and extend RT. We'll cover upgrading and deploying RT, database tuning, advanced Lifecycle configurations, writing tools with RT's API, building an extension, and demonstrate how to extensibly alter the web UI and internal functions.

It goes without saying that you'll get the most out of training if you attend both days of the course, but we've designed the material so that you can step out after the first day with a dramatically improved understanding of how to use RT.

For both days, the cost is USD $1,495. A single day is USD $995. Each class includes training materials, a continental breakfast, and snacks (lunch is not provided).

If you'd like to pay with Visa, MasterCard or Discover, please visit Best Practical's online store. Unfortunately we are unable to accept American Express or PayPal. If you'd prefer to pay with a purchase order, please email us at training@bestpractical.com. Be sure to include:

• If you want to attend both days or a single day
• Full names and email addresses of attendees

Please contact us at training@bestpractical.com for discounted pricing if you are from an academic institution or if you'd like to send more than 3 people.

Thanks for your support of Request Tracker!

Don't miss Best Practical's first Request Tracker training of 2014 in London!

Just a reminder that Best Practical's first RT training is taking place on March 19-20 in London, UK. This will likely be our only non-US public session this year. This training will introduce you to the new features in RT 4.2 as part of a comprehensive overview of RT. Whether you've been using Request Tracker for years or are a recent convert, you'll have a good understanding of all of RT's features and functionality by the end of the session.

For both days, it is USD $1,495 for one person. This includes training materials, continental style breakfast, and snacks. You can register by heading over to our shop to pay via credit card (Amex not accepted, unfortunately.) You can also drop us a note at training@bestpractical.com if you'd rather we send an invoice. Finally, if you're from an academic institution, or would like to send more than 3 people, let us know so we can give you a bit of a discount. We're always happy to answer any questions, so please don't be shy.

RT public training in London

Our first training for 2014 will take place in London, England on March 19-20.As we like to keep class sizes relatively intimate, register soon or we may not be able to guarantee you a seat. If you can't make London, we will have upcoming trainings this year in Dallas, Texas and Boston, Massachusetts. Please let us know at training@bestpractical.com if you're interested in these other trainings, or if you have a suggestion for where we should hold one.

This training will introduce you to the new features in RT 4.2 as part of a comprehensive overview of RT. Whether you're an old hand at RT or a recent convert, you'll have a good understanding of all of RT's features and functionality by the end of the session.

The first day starts off with a tour of RT's web interface and continues with a detailed exploration and explanation of RT's functionality, aimed at non-programmer RT administrators. We'll walk through setting up a common helpdesk configuration, from rights management, constructing workflows and notifications, and the basics of Lifecycles.

The second day of training picks up with server-side RT administration and dives into what you need to safely customize and extend RT. We'll cover upgrading and deploying RT, database tuning, advanced Lifecycle configurations, writing tools with RT's API, building an extension, and demonstrate how to extensibly alter the web UI and internal functions.

It goes without saying that you'll get the most out of training if you attend both days of the course, but we've designed the material so that you can step out after the first day with a dramatically improved understanding of how to use RT or show up on the second day and get quickly up to speed on how to make RT do your bidding.

For both days, the cost is USD $1,495. Single days are USD $995. Each class includes training materials, a continental breakfast, and snacks (lunch is not provided).

If you'd like to pay with Visa, MasterCard or Discover, please visit Best Practical's online store. Unfortunately we are unable to accept American Express or PayPal. If you'd prefer to pay with a purchase order, please email us at training@bestpractical.com. Be sure to include:

• If you want to attend both days or a single day
• Full names and email addresses of attendees

Please contact us at training@bestpractical.com for discounted pricing if you are from an academic institution or if you'd like to send more than 3 people.

Security vulnerability in RT 4.2

Versions of RT between 4.2.0 and 4.2.2 (inclusive) are vulnerable to adenial-of-service attack via the email gateway; any installation which accepts mail from untrusted sources is vulnerable, regardless of the permissions configuration inside RT. This vulnerability is assigned CVE-2014-1474.

This vulnerability is caused by poor parsing performance in the Email::Address::List module, which RT depends on. We recommend that affected users upgrade their version of Email::Address::List to v0.02 or above, which resolves the issue.

After extracting the contents, the module can be installed by running:

perl Makefile.PL
make
make install

The first step should be sure to use the same perl that RT runs using. If you are unsure, the first line of /opt/rt4/sbin/standalone_httpd should contain the full path to the relevant perl binary. The last step will likely need to be run with root permissions. After this process, you should restart your webserver.

If you need help resolving this issue locally, we will provide discounted pricing for single-incident support; please contact us at sales@bestpractical.com for more information.

RT 4.2.2 released

We are pleased to announce that RT 4.2.2 is now available.This release is primarily a bugfix release; of particular note is that it contains schema changes for MySQL. Though the changes are limited, it is especially important to take, and verify you can recover from, a database backup prior to upgrading.

Also notable is that this release fixes a bug in 4.2.0 and 4.2.1 where failures of the HTML-to-text conversion would silently cause mail to fail to be sent. When using the rich text editor, RT will also now quote the the HTML parts of email, and not simply their text equivalents.

Other changes include:

Documentation

• Wording fixes in Shredder
• Clean up examples in Lifecycles documentation
• Document additional indexes that increase performance of Shredder
• Replace a suggested GnuPG option with one which is not deprecated
• Note that errors reported from the GnuPG infrastructure may be caused by GnuPG not being configured, but having been automatically enabled.

Database

• Ensure that even disabled scrips get the same id-to-name change that other scrips got during the 4.0 → 4.2 upgrade.
• On MySQL, alter the character set of all columns used to store email addresses to UTF-8
• Ensure that invalid byte sequences that may have snuck into the database previously (on earlier versions on MySQL, for instance) are not blindly interpreted as UTF-8 when retrieved from the database. As a result, invalid bytes will be returned from the API as the four characters "\xHH", where HH is the hexadecimal encoding of the byte.
• Ensure that all data containing non-ASCII is quoted-printable encoded for PostgreSQL, instead of merely all data not claiming to be text/plain
• Additional warnings prevention on Oracle; tests now pass cleanly
• Allow fully-automated database upgrades using --upgrade-from and --upgrade-to options to rt-setup-database
• Clean out any remaining traces of RTFM that lingered in custom fields and custom field values that were disabled at the time of the previous upgrade step.
• Bullet-proof a 3.8 → 4.0 upgrade step for Scrips with no Condition

Serializer/importer

• Install rt-serializer and rt-importer into sbin/
• Ensure that incremental upgrade steps only run on incremental serializations, not all exports
• Fix a runtime error in the incremental upgrade path to 4.2
• Ensure that inflated Users and Groups are created with the same id as their Principal
• Disable in-memory record caching when serializing and importing to improve performance
• Only search non-Disabled custom fields when looking up BasedOn in initialdata files
• Set up logging properly; warnings are now displayed during serialization and importing

Email

• Don't die if HTML → text conversion throws an error, which would silently prevent outgoing mail from being sent. Instead, fall back to just sending text/html with no text/plain
• Replying to an HTML mail with the rich text editor will now quote the HTML part, not the equivalent text version.
• Set a transfer encoding on outgoing dashboards; this resolves issues with long lines when using the Sendmail MTA.
• Cope with mangled and overly-quoted recipient headers occasionally generated by Outlook.

General user UI

• Stop localizing custom field names, for consistency
• Show a useful error on "show outgoing mail" if the user has no rights to see the page, rather than displaying an empty page.
• Adjust UI to not block header on "show outgoing email" page
• Hide the Take and Steal menu items if you already own the ticket, closing a regression in 4.2.0 and above.
• Autocompletion custom fields now properly autocomplete when placed in custom field groupings
• Improve rendering on Internet Explorer 6
• Fix cascaded custom fields on Internet Explorer 8 and below.
• Fix third-level cascading custom fields, broken in 4.2.1
• Minor rendering bugs with Charts placed on homepages and dashboards
• Whitelist "show outgoing email" and chart results from CSRF protection
• RT 4.0.7 introduced a performance regression when building ticket searches that query Links; switch back to a much better-indexed query.
• Fix "Clone ticket" functionality with Select-multiple custom fields.
• Show the queue ID for the current queue in the ticket edit page, even if the user does not have SeeQueue; this prevents the user from accidentally changing the queue.
• Respect custom field groupings on user preferences page

Query Builder

• Warnings avoidance for searches with more than 1000 results.
• Allow IS NULL to search for dates which are unset
• Properly quote CF names containing non-ASCII characters in query builder, broken since 4.2.0
• Add "UpdatedBy" TicketSQL limit

Admin

• Correct a package load order problem which prevented the web installer from working since 4.2.0
• Report the correct setting name in rt-validate-aliases
• Fix real-time updating of Theme CSS on Internet Explorer 8 and below
• Fix a minor display bug in the CF Admin pages, where the queue number instead of queue name would be displayed in requests shortly after server startup.
• Add "Extra Info" as a possible field for "More About Requestor"

REST

• Allow searching for users, queues, and groups in REST
• Prevent a server error when attempting to guess content-type in the REST interface.

Development

• Allow running tests with an explicit set of plugins enabled.
• Custom Action and Condition packages (as supplied by extensions; these are not the text entry boxes in the UI) are now loaded at server startup time, to catch compile-time errors in such classes early as well as reducing RT's memory footprint on mod_perl. Previously, these errors would have logged errors only when their Scrip failed to fire. This restores the behavior found in RT 3.8, which was mistakenly removed in RT 4.0.0.
• Additional callbacks, including in charts, and on ticket reply pages
• Remove an unused Makefile target

A complete changelog is available from git.

RT 4.0.19 released

We are pleased to announce RT4.0.19 is now available. This release is primarily a bugfix release; of particular note is that it contains schema changes for MySQL, the first notable such in the 4.0 series. Though the changes are limited, it is especially important to take, and verify you can recover from, a database backup prior to upgrading.

Other changes of note:

Documentation

• Add documentation for rt-crontool
• Clean up examples in Lifecycles documentation
• Document additional indexes that increase performance of Shredder
• Replace a suggested GnuPG option with one which is not deprecated
• Note that errors reported from the GnuPG infrastructure may be caused by GnuPG not being configured, but having been automatically enabled.

Database

• On MySQL, alter the character set of all columns used to store email addresses to UTF-8
• Ensure that invalid byte sequences that may have snuck into the database previously (on earlier versions on MySQL, for instance) are not blindly interpreted as UTF-8 when retrieved from the database. As a result, invalid bytes will be returned from the API as the four characters "\xHH", where HH is the hexadecimal encoding of the byte.
• Ensure that all data containing non-ASCII is quoted-printable encoded for PostgreSQL, instead of merely all data not claiming to be text/plain
• Additional warnings prevention on Oracle; tests now pass cleanly
• Allow fully-automated database upgrades using --upgrade-from and --upgrade-to options to rt-setup-database
• Clean out any remaining traces of RTFM that lingered in custom fields and custom field values that were disabled at the time of the previous upgrade step.
• Bullet-proof a 3.8 → 4.0 upgrade step for Scrips with no Condition

Email

• Set a transfer encoding on outgoing dashboards; this resolves issues with long lines when using the Sendmail MTA.
• Cope with mangled and overly-quoted recipient headers occasionally generated by Outlook.

General user UI

• When using the back button to return to a reply page with the rich text editor, contents will no longer be doubly HTML-encoded
• Improve rendering on Internet Explorer 6
• Fix cascaded custom fields on Internet Explorer 8 and below.
• Support cascaded selects for all Select render types (dropdown, select box, radio buttons, checkboxes)
• Minor rendering bugs with Charts placed on homepages and dashboards
• Add "mark as seen" functionality to SelfService ticket display pages
• Link the ModifyPeople page when the user has Watch or WatchAsAdminCc
• Whitelist "show outgoing email" and chart results from CSRF protection
• RT 4.0.7 introduced a performance regression when building ticket searches that query Links; switch back to a much better-indexed query.
• Fix "Clone ticket" functionality with Select-multiple custom fields.
• Show the queue ID for the current queue in the ticket edit page, even if the user does not have SeeQueue; this prevents the user from accidentally changing the queue.

Query Builder

• Support CF.Foo in addition to CF.{Foo} and '__CF.{Foo}__' in format strings. This follows the trend of allowing brace-less forms whenever possible.
• Ensure that format strings from the Query Builder escape quotes correctly, and correctly parse existing formats with quotes.
• Autocomplete CF values for custom fields of type "Autocomplete" in the Query Builder.
• Warnings avoidance for searches with more than 1000 results.

Admin

• Fix real-time updating of Theme CSS on Internet Explorer 8 and below
• Fix a minor display bug in the CF Admin pages, where the queue number instead of queue name would be displayed in requests shortly after server startup.
• Add "Extra Info" as a possible field for "More About Requestor"

iCal

• Ensure that iCal dates are formatted with a leading space on the first nine days of each month, for correctness.
• Show iCal dates (when omitting times) in the user's timezone, not UTC

REST

• Prevent a server error when attempting to guess content-type in the REST interface.

Development

• Custom Action and Condition packages (as supplied by extensions; these are not the text entry boxes in the UI) are now loaded at server startup time, to catch compile-time errors in such classes early as well as reducing RT's memory footprint on mod_perl. Previously, these errors would have logged errors only when their Scrip failed to fire. This restores the behavior found in RT 3.8, which was mistakenly removed in RT 4.0.0.
• rt-dump-metadata has slightly more documentation and options
• Additional callbacks, including in charts, and on ticket reply pages
• Show customized rights under their appropriate categories
• Remove an unused Makefile target
• Ensure that RT::Template->Create returns (result,message) and not simply result

A complete changelog is available from git.

What's New in 4.2: Scrips Configuration

In RT 4.2 we've updated the scrips configuration pages and the changes will save RT admins a bunch of time when managing scrips. Specifically, you can now apply scrips globally or to selected queues on one simple configuration page.

Disabling a Scrip on Just One Queue

RT's global scrips work for most notifications, often with just some updates to the global templates. If you want different templates for specific queues, you can create a queue-specific template with the same name as the global template and the global scrip will use that template for notifications on that queue.

But what if you want to disable a notification for just one queue and leave it on for all the others? In previous versions of RT, this meant disabling the global scrip, then creating a new scrip in each queue that still needed it. In RT 4.2, this is now much easier.

For example, let's assume we have an Office queue for internal office requests and everyone agrees we don't need to see the 'On Resolve' notification when the new staples have come in. First we go to Admin > Global > Scrips and click on the "On Resolve Notify Requestors" scrip.

On the Basics page you'll notice a new Applies to label showing "Global" and a check box to enable and disable the scrip. You could previously disable scrips in a dropdown menu in the same location, but the other items in the dropdown were the scrip stages, so users often didn't know the Disabled option was in there.

The current options are fine for our case, so we click on the Applies to link in the submenu. The resulting page says "Applies to all objects", meaning the scrip is currently global. Below that is a checkbox you can check to remove the scrip from all objects. We check that and click Submit to see the new Modify page.

The new page displays all of our queues with checkboxes so we can check all queues but the Office queue. You can also change the scrip stage (normal or batch) or change the template at this point.

After we submit, we see the scrip has been applied to the selected queues.

You can now easily move scrips between queues or make it global again.

Scrip Order

From the scrip listing pages, at both the global and queue level, you can now also manage the order in which scrips run. For default configurations, this isn't an issue for most notifications, but as you add more scrips you sometimes want to guarantee that one scrip will run before another for the same sort of update (comment, correspond, etc.). To change the order, just click the Up and Down links on the right.

You'll also notice we now separate regular scrips and batch scrips to make the running order more clear. Batch scrips run at the end of a transaction after all other scrips have run.

Scrips that are not applied appear at the bottom of the screen and you can easily select and apply them either globally, if you're on the global modify page, or on the current queue if you're on a queue-specific scrip page.

Summary

These updates should make it much easier to reuse scrips across a portion of the queues in your system and selectively apply them. The new scrip display and ordering features should also make it easier to view and control when they run.

If you'd like to learn about more new features in 4.2, take a look at the new feature overview.

What's New in 4.2: Grouping Custom Fields

In RT 4.2 we've added some new configuration options that allow you to cleanly organize your custom fields, improving the look of pages and making it easier to view and update custom field data.

Ticket Custom Field Grouping

The new configuration goes in your RT_SiteConfig.pm file, as usual, and can be used for ticket and user custom fields. A simple configuration to group together a few ticket custom fields on a support queue might look like this:

Set(%CustomFieldGroupings, 'RT::Ticket' => [ 'Product Details' => ['Products', 'Current Version', 'Database'], 'Basics' => ['SLA'], ], );

The first entry under RT::Ticket will create a new "Product Details" grouping and include the three custom fields listed. You can add more entries and custom fields to set up as many new groups as you need. If you have additional custom fields not assigned to a group, they will appear in the standard Custom Fields portlet as usual.

The second entry shows another nice feature, which is the ability to include custom fields in existing ticket groups. You can't remove or reorder core RT fields in these groups, but you can add custom fields to them. The standard RT groups are:

For Tickets: Basics, Dates, Links, People For Users: Identity, Access control, Location, Phones

With the configuration above, the ticket display page will now look like this:

The ticket groupings appear on the ticket create, display, and update pages. The ordering of the custom fields in each group is still controlled by the queue configuration. You can find this by going to Admin > Queues, clicking on a queue, then selecting Custom Fields > Tickets in the submenu. Just click Up/Down on the configuration page to change the ordering.

The custom field groupings also apply to RT's self service pages. You might want your customers to set some custom fields to help with support requests, so you can give them permission to see and edit selected custom fields even though they are unprivileged users. They can then fill out some fields as part of their support request.

User Custom Field Grouping

Adding a grouping for some user custom fields might have a configuration like this:

'RT::User' => [ 'Focus Areas' => ['Product Areas', 'Primary Roles'], 'Location' => ['Base Office'], ],

Which adds the following to the user page:

You can find details on the new custom field grouping features in the RT_Config documentation. We think you'll find this a nice way to bring some order to you custom fields.

If you missed some earlier posts, you can find more new RT 4.2 features in the new feature overview.

What's New in 4.2: User Summary Page

In the user administration section, you'll find a new User Summary page in RT 4.2. This new page pulls together current information related to a given user in one convenient place, making it a natural destination for links from usernames throughout the RT interface.

To get to the new User Summary page, you'll find links in all of the normal places where a username is display. This includes ticket listings that show requestor or owner, ticket histories, and the People section on tickets. There is also a User Summary link in the "More about the requestors" section on the ticket display page. The ticket listings on the User Summary page itself have links as well, making it easy to jump to another owner or requestor.

As you can see above, the top of the page contains a search for finding other users in the system. Like other user fields, it provides auto-completion to make it easier to track down the right user by name, email address, or real name.

The page then has a short summary identifying the user, followed by a Quick ticket area that allows you to easily create a new ticket on behalf of the user. This is convenient when a request comes in on your cell phone or just a "drive-by" office request, or when a new request or task springs from an existing ticket and the user you're looking at should be the requestor.

The bottom of the screen displays a summary of active and inactive tickets similar to the summary in "More about the requestors," but with more data. This section displays tickets where the user has some sort of watcher relationship. If you're looking at the page for a staff member, you'll see active and inactive tickets where they are the owner. For customers, you'll see tickets where they are the requestor.

Finally, when you need to update some user information, the user Edit and Membership links are available in the submenu at the top.

If you missed some earlier posts, you can find more new RT 4.2 features in the new feature overview.

What's New in 4.2: New Charting Features

RT 4.2 adds the ability to chart several different aspects of ticket data at the same time with new grouping options. You can also chart various calculated values to get more from your time data.

As with earlier RT charts, the first step is to build a query to search for the tickets you want to chart. Your search might focus on a particular queue and you might only want to see tickets in a selected time period. Once you have your search and click on the Chart link from the submenu on the search results, you'll see new Group by and Calculate options below the initial default chart.

The Group by section allows you to define up to three levels of grouping to chart your ticket data. For example, you might want to see the owners of all of the tickets in your selected queue and how many tickets each owner has. To view that, you just select Owner in the first "Group tickets by" section. Depending on the view you want, you can have the owner label display using name, email address, real name, or some other user field.

As you're looking at that chart, you might wonder how many of those tickets are in each status. Are they mostly resolved, or are people juggling a bunch of open tickets? To see the status information, you can select Status from the next dropdown under "and then." That would give you a chart and table that looks something like this:

RT tickets have many date and time fields, some automatically set for you by RT like Created and Resolved, and some optionally set by you like Time Estimated and Time Worked. These fields can be helpful in determining where people are spending their time and how well tickets are moving. The new Calculate section on the Charts page makes it very easy to generate charts and tables from this data.

For example, you might want to see how long tickets are in the new status before someone has time to take and open them. You can get this value by looking at the difference between Created (when RT initially created the ticket based on a request) and Started (when the ticket was opened). On the Charts page, you can set the Group by section to only Queue. In the Calculate section you can select Created-Started, leaving the second dropdown set to the Summary option. When you click Update Chart you get a chart and table showing you the Minimum, Average, Maximum, and Total time tickets spent in the new status for the selected queue.

Like the Group by section, you can now also select multiple criteria in the Calculate section to display at once. So after seeing the time spent in new, you might also want to see how long tickets were active before being resolved. In the Calculate section you can use the second section below "and then" and select Started-Resolved and leave the initial Summary option. Clicking Update Chart you now have all the same values for the time the ticket was active.

While all of that information is interesting, you might decide the chart and table are a bit busy with all of those values. If you look in the second dropdown in the Calculate section, you'll see you can select each calculated value individually. You might want just Average for both values to get a general idea how long things are taking.

Pulling it all together, you can select Queue and Owner from the Group by section, and a combination of times and ticket count to generate a graph and table like the one below.

Adding the count mixes the units a bit and you can see that the chart units are set by the first calculate criteria (time in this case). But adding the count is a good way to give perspective to the averages. In this case it shows that while holmes' averages look good, he only worked on 1 ticket.

You'll find there a many new ways to mix and display your data to get more information from your ticket system. As always is the case, the better you follow your processes (taking, opening, resolving tickets) and track data (if you use the other time fields), the more useful the data will be. And once you create the charts you want, you can save them and create a convenient dashboard so you can easily check them.

You can read more about charts in the new charts section in the RT documentation. If you missed some earlier posts on the new features in RT 4.2, you can find more in the new feature overview.