New Web UI for RT Actions and Conditions

Best Practical is happy to announce the release of a new extension providing an administrative web interface to RT conditions and actions. In RT you can define custom conditions and actions directly through the web UI using the "User Defined" option in scrips, but previously you needed to run a small script to register new conditions and actions defined in module files. This new web UI now makes it easy to register these with a few clicks.

Also, with the new interface, you can easily reuse existing conditions and actions that accept arguments as part of their configuration. The StatusChange condition, for example, accepts a status to determine if the current transaction is changing to that status (e.g. On Resolve). With the new web UI, you can easily copy an existing status change condition and create a new one for a custom status you may have configured in a lifecycle.

Some actions work with arguments as well. NotifyGroup, for example, can send notifications based on several different arguments including RT groups or even an email address. RT provides the rt-email-group-admin script to create these from the command-line, but now an RT admin can create new notification actions just as easily from the web interface and can edit them later when they need to be updated.

We hope making it easier to add custom conditions and actions will encourage more people to think about new ways to automate their RT workflows. In addition to providing the new UI, the extension contains new condition and action documentation to get you started. The new extension works with RT 4.0 and 4.2 and the functionality will be pulled into RT in future versions.

As always, bug reports or comments are welcome at bug-RT-Extension-AdminConditionsAndActions@rt.cpan.org, pull requests via github.

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.

RT 4.2.1 released

We're pleased to announce that RT 4.2.1 is now available. This release is primarily a bugfix release; notable changes include:

Oracle:

• Resolve numerous issues with the 4.0 → 4.2 upgrade steps on Oracle
• In-database sessions on Oracle are no longer truncated at 8k, leading to spurious logouts

Internet Explorer:

• Fix submission issues under Internet Explorer

Rich text editor:

• If returning to a reply/correspond page with the back button, the rich text editor will no longer double-escape previously written content.

REST:

• Fix an empty text/plain part when tickets are created using the REST interface.

Other bugfixes:

• Optimize transaction display code to speed up long ticket displays by short-circuiting transaction custom field checking.
• Supply a default $PATH for SMIME and GnuPG under FastCGI
• Support index upgrade steps on Pg when in a custom schema/li>
• Close a memory leak in ColumnMap/li>
• Fix "check all" checkboxes for new jQuery version/li>
• Secondarily sort user ticket lists by id, as well as priority./li>
• Remove call to deprecated function used by PreviewScripMessages/li>
• Many localization fixes (thanks to Emmanuel Lacour)/li>
• Show customized rights in their correct tabs/li>
• Ensure RFC2822 date format uses two-digit days in output/li>
• Display iCal dates in the user's timezone, resolving off-by-one errors for timezones significantly off from GMT.
• Correctly parse complex format strings for listing in the bottom of the Query Builder

Callbacks

• Move ModifyQueryProperties callback to before its values are used
• Additional callbacks on ticket modify pages
• Additional callbacks on ticket reply/comment page
• Additional callback on search results page
• Additional callback before transactions in history list
• Allow header callback to modify %ARGS

Features

• Allow bulk update to delete all CF values for a given CF
• Support CF.Foo in columnmaps, in addition to CF.{Foo} and __CF.{Foo}__
• Autocompletion CFs now autocomplete in search builder
• Support cascaded selects with any combination of listbox, dropdown, and radio button
• Support ShowUnreadMessageNotifications in SelfService

A complete changelog is available from git.

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.

RT 4.0.18 released

We're pleased to announce that RT 4.0.18 is now available. This release is primarily a bugfix release; most notably, it addresses compatibility issues with recent versions of the Encode perl module.Notable changes include:

Email

• Cope with Encode version 2.33 and later, which altered their internal functionality and caused RT to double-encode Subject lines in outgoing email.
• Fix HTML rendering errors in dashboard emails.
• Fix overzealous quoting around decoded MIME words.

Administration

• In the rights UI, entering the name of a user or group which already has rights will now correctly select them for rights granting, as if their name had been selected.
• Display types in the "applies to" dropdown for custom fields in consistent order
• Paginate the Queues list in the administrative interface into 50 results per page.
• Support for cascading selections with a multiple-select parent.
• Clarify that $ParseNewMessageForTicketCcs only applies to new, and not existing, tickets.
• Clarify how an undefined $RTAddressRegexp is treated, and that it does not come at any notable performance penalty.

Logging

• Fix verbosity of syslog messages; now only the 'debug' level includes originating filename and line.
• Include process ID in log messages, for ease of isolation in a multi-process environment.
• Log the From: address of incoming mail which triggered an error, for ease of debugging.

Other Bugfixes

• Avoid linking trailing punctuation, or html tags, in URL anchors in MakeClicky
• Fix the Quick Search (QueueSummary) portlet when non-lowercase statuses are used.
• Show Date and DateTime custom fields in the user's format and time zone in search results.
• Allow rt-email-group-admin to be passed an email address that RT is not already aware of.
• Show submitted content from the user on errors in REST submission, for ease of re-editing and re-submission.

A complete changelog is available from git.

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.

RT 4.2.0 released

We're incredibly pleased to announce the availability of RT 4.2.0 - thefirst release for the next major version of RT. This release adds exciting new functionality, as well as streamlining and generalizing the internals.

When upgrading, please be sure to review the upgrading documentation available in docs/UPGRADING-4.2, as there are a number of backward-incompatible changes that come along with the new version number.

A partial list of the new features in RT 4.2.0 is included below, and on our website. Many of the new features will also be described and demoed in a series of blog posts on this blog in the coming weeks.

If you have questions as you upgrade, please don't hesitate to write to rt-users@lists.bestpractical.com for community support. If you'd rather have professional support from the folks who built RT, drop us a line at contact@bestpractical.com.

• Much improved reporting via search result charting
  • Multiple group by and statistic calculations in a table
  • Time statistics such as average, minimum, and maximum durations between Created and Resolved, Created and Started, Started and Resolved, and more.
  • More robust layout of charts
• Increased performance for searches and ticket pages
  • Faster searches on all databases (especially Pg)
  • Ticket pages load quicker
  • Menus load before the rest of the page is loaded
  • History is loaded asynchronously
  • Faster serving of static assets
• Scrips per queue
  • Apply scrips globally or ad-hoc to individual queues, á la custom fields
  • Less duplication of scrips and/or need for empty templates
• Custom field groupings
  • Display CFs in configurable groupings (boxes) on the ticket display/edit pages
  • Includes arbitrary grouping names as well as standard ticket groupings (Basics, Dates, People, Links, etc.)
• User summary pages
  • Display information about users such as tickets, history, groups, etc.
  • An extended "More about requestors" page for any user
  • Easy to get to via links and user search
• HTML templates enabled by default for new installs, available for upgrades too
• Ticket display improvements
  • Rich text/HTML messages are preferred for display by default
  • Images are inlined with text in ticket history display instead of presented at bottom
  • Clickable users, tickets, articles, and other items
• Many interface improvements, such as:
  • Improved menu layout
  • Per-user preferences for the dashboards which appear in the Home menu
  • Floating page menu for quicker access to ticket actions, subpages, etc.
  • Autocomplete for ticket links, including when merging
  • Autocomplete available to self service users
  • Improved CF and links display in search results
  • Sticky simple search for quick search refinements
  • Attachments on reply can no longer be mixed up when replying to multiple tickets at once
  • ReassignTicket right to assign tickets without stealing first; useful for managers
• S/MIME support integrated with GnuPG support
  • Decrypt and verify incoming GPG and SMIME messages
  • Send all outgoing messages as either GPG or SMIME
• Migration tools
  • Migrate from one database type to another (MySQL, Pg, Oracle)
  • Merge multiple RT instances together
• Thousands of bug fixes; nearly 2000 commits totalling more than 250,000 lines of code changed.

RT 4.2.0rc5 Released; Assets extension

We're pleased to announce the availability of RT 4.2.0rc5 - the fifthrelease candidate for the next major version of RT. This release corrects encoding errors with new versions of the Encode module and rendering of fonts in pie charts.

We look forward to hearing your experiences installing or upgrading to this release; the more feedback we get, the sooner the official release of RT 4.2.0 can occur. Bear in mind that reports of successful installs and upgrades are just as important as reports of issues.

Please be sure to review the upgrading documentation available in docs/UPGRADING-4.2, as there are a number of backward-incompatible changes that come along with the new version number.

---

We are also pleased to announce we have made public our development branch of Assets for RT. This extension requires RT 4.2.0rc5 or above; while no official release has been made, we welcome your testing and comments. We expect to make an official release candidate for Assets 1.0 within the next several weeks.

RT 4.2.0rc3 Released

We're elated to announce the availability of RT 4.2.0rc3 - the third release candidate for the next major version of RT. Barring any surprises, we expect 4.2.0 to ship early next week.

We would be thrilled to hear your experiences installing or upgrading to this release candidate; the more feedback we get, the sooner the official release of RT 4.2.0 can occur. Bear in mind that reports of successful installs and upgrades are just as important as reports of issues.

As always, please review the upgrading documentation available in docs/UPGRADING-4.2, as there are a number of backward-incompatible changes that come along with the new version number. If you are upgrading from 4.2.0rc2, the differences are merely cosmetic.

We have also begun scheduling our services for upgrades in anticipation of the final RT 4.2.0 release. If you have questions about upgrading or other aspects of RT 4.2.0 you can get in touch with us at contact@bestpractical.com.