RT 4.4.0 release candidate 1 released

We're extremely excited to announce the availability of RT 4.4.0rc1: the first release candidate for the next major version of RT. 

We would be thrilled to hear your experiences installing or upgrading to this release; the more feedback we get, the sooner the official release of RT 4.4.0 can occur. Please be sure to review the upgrading documentation available in docs/UPGRADING-4.4, as there are a number of backward-incompatible changes that come along with the new version number.

 

In addition, to help kick off RT 4.4, we're having a public training session in Chicago on December 14-15! This two-day session covers RT basics, as well as development, and will highlight the new features in today's release candidate. If Chicago isn't a good fit for you, we'll be having public sessions in Washington DC, and Hamburg, Germany, in Q1 and Q2 of 2016 (respectively). To purchase a seat via credit card for the Chicago training, please visit shop.bestpractical.com. If you prefer to pay via other methods, or you have questions, please write in to training@bestpractical.com. And, as always, we welcome suggestions for training locations in the future.

 

A list of the major new features in RT 4.4.0 is included below. Many of the new features will also be described and demoed in a series of blog posts here on blog.bestpractical.com in the coming weeks.

  

• RT now includes the Assets extension for tracking your physical and digital resources.
• Attachments can now be stored outside of the database either on disk, in Dropbox, or on Amazon S3. Attachments can also be directly served from S3.
• SLA tracking is now part of core RT. You can define many different service levels that take your business hours and holidays into account.
• External authentication and LDAP integration are now shipped as core RT features.
• RT now has support for custom roles, along the lines of Requestor, Owner, Cc, and AdminCc. These roles can be single-member or multi-member. Privileges can be assigned to members of custom roles, you can search based on custom role membership, you can notify custom role members in scrips, and so on.
• RT now has a modern file upload interface which allows you to select multiple files in one fell swoop, drag and drop attachments onto RT, and inline preview certain file types like images.
• We've added a "scroll" option for gradually loading in ticket history as the user scrolls down, much like "infinite scroll". This considerably improves perceived performance.
• Existing attachments on a ticket can be reused in subsequent replies, so you don't have to upload them again.
• We now provide some basic Articles configuration for new deploys so that you can start using the feature immediately.
• You can now break up your RT_SiteConfig.pm file into logically-related chunks under the RT_SiteConfig.d/ directory.
• You can now specify default values at the queue level for certain ticket fields, including custom fields.
• RT now warns you when you write the word "attach" (or "attached", etc) but haven't provided any attachments yet, to avoid "sorry, I forgot this attachment" followup mail.
• RT now understands many more types of "human" date strings.
• Users can now choose any subset of the seven weekdays to receive their daily dashboard subscriptions.
• The query builder display format panel has seen several improvements; most importantly adjusting the display columns no longer reloads the entire page.
• We've added a popout ticket timer for helping you track time inside RT. The timer is associated with a ticket and will add the time to it for you.
• RT now ships with keyboard shortcuts for primarily for navigating ticket search results.
• We ship a (disabled-for-upgrades, enabled-for-new-deploys) scrip for carrying over time worked to parent tickets. Similarly, we ship a scrip for tracking time worked per user.
• We've added a way to quickly create new linked tickets in queues other than the one that the current ticket is in.
• There's a new site-level config setting and user preference for hiding unset fields on ticket display pages.
• Custom fields now have a customizable "entry hint" for helping users understand what they should be entering as values.
• TicketSQL and the search builder now support Status = '__Active__' and Status = '__Inactive__' type queries, so you no longer need to enumerate all statuses like Status = 'new' OR Status = 'open' OR Status = 'stalled'
• The mailgate has been completely redesigned and modernized.

 For more information including a complete list of changes please see our official release announcement.

 

RT 4.2.12 released

We have released RT version 4.2.12 to resolve CVE-2015-5475 and another XSS vulnerability. See the release notes for a complete list.

RT 4.0.24 released

We have released RT version 4.0.24 to resolve CVE-2015-5475. See the release notes for a complete list.

Security vulnerabilities in RT

We have discovered security vulnerabilities which affect both RT 4.0.x and RT 4.2.x.  We are releasing RT versions 4.0.24 and 4.2.12 to resolve these vulnerabilities, as well as patches which apply atop all released versions of 4.0 and 4.2.

 

The vulnerabilities addressed by 4.0.24, 4.2.12, and the below patches include the following:

 

RT 4.0.0 and above are vulnerable to a cross-site scripting (XSS) attack via the user and group rights management pages.  This vulnerability is assigned CVE-2015-5475.  It was discovered and reported by Marcin Kopeć at Data Reliance Shared Service Center.

 

RT 4.2.0 and above are vulnerable to a cross-site scripting (XSS) attack via the cryptography interface.  This vulnerability could allow an attacker with a carefully-crafted key to inject JavaScript into RT's user interface. Installations which use neither GnuPG nor S/MIME are unaffected.

 

Patches for all releases of 4.0.x and 4.2.x are available (signature). Versions of RT older than 4.0.0 are unsupported and do not receive security patches; please contact sales@bestpractical.com if you

need assistance with an older RT version.

  

The README in the tarball contains instructions for applying the patches.  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.11 released

We have released RT version 4.2.11. This is a bugfix release; most notably, it improves indexing time for full-text search, as well as improving support for Apache 2.4 and MySQL 5.5. Interactive command-line tools (including upgrade tools) will now also default to displaying warnings to STDERR, to aid in awareness of potential errors.

See the release notes for a complete list.

Jifty's Request Inspector

We're experimenting with mirroring technical articles written by Best Practical engineers. This article is about a component of Jifty, our web framework.

Jifty's RequestInspector plugin provides you with debugging information for HTTP requests. You can examine the SQL queries that were issued in servicing the request, inspect a Devel::NYTProf profile of the request, and more. The information is presented in an (admittedly ugly) admin panel. Here's what our Changelogger's request inspector page looks like:

If we click into one of the requests, we can get an overview of that request.

We can inspect in detail a particular part of a request with another click.

Backend

The frontend is good enough. It gets the job done. But what I am really interested in, and what I had far more fun creating, is the backend that powers this.

RequestInspector is a Jifty plugin. Its job is to manage all of the other plugins that inspect requests (such as SQLQueries, DumpRequestResponse, NYTProf, and Gladiator). RequestInspector informs the plugins of interesting events such as: a new request is beginning, that request finished.

Each plugin produces various kinds of data. That data is completely opaque to RequestInspector. The data can be an object, a number, a code reference, or whatever else. All RequestInspector does is keep track of that data, handing the data to the plugin when it needs to do something with the data.

When a new request begins, RequestInspector calls the inspect_before_request method on each plugin. When the request ends, inspect_after_request is called on each plugin. The interesting bit is that the opaque data is threaded between the return values and parameters of these methods. The return value of inspect_before_request is passed to that plugin's inspect_after_request. inspect_after_request's return value is stored for later rendering. (In what amounts to a global variable — sorry!)

When the user wants to see a request, RequestInspector calls the inspect_render_summary method on each plugin. When the user wants to see the detailed analysis by a particular plugin for a particular request, RequestInspector calls the inspect_render_analysis method on that plugin. It is completely up to the plugin to decide what to render. Both methods receive the data it returned from inspect_after_request for that request.

Benefits

You might wonder why this design is better than, say, a specific data format to which each plugin must adhere.

It is unclear what such a data format would look like. I don't think a single data format could usefully encompass the different kinds of data that these plugins produce. While SQLQueries's data is complex data structure with a lot of information, NYTProf's is basically just a random number used to track the on-disk profile directory.

The format would certainly evolve over time. This means that plugins would have to change as well just to keep up with RequestInspector. With my design, plugins really only need to change when they want to support newer RequestInspector features.

It's simpler for plugins to let them dictate how they want to store whatever they are tracking. It's simpler for the RequestInspector core too, since it is free from having to examine the plugins' data.

Finally, the RequestInspector plugin can get arbitrarily complex and the plugins do not have to care about it. The RequestInspector already lets you filter out URLs you know you will not want to inspect. The individual request inspector plugins do not have to implement that functionality.

In the future, I plan to add a feature to RequestInspector that lets you see which requests took the most amount of database time, or leaked the most amount of memory, etc. All the feature will require of plugins is that they implement an optional inspect_compare_requests method. The method will receive that plugin's data from two requests and returns -1, 0, or 1. So trivial that I should just do it now.. :)

Basically, RequestInspector leverages the Principle of Least Knowledge to keep things simple, easy, and flexible. Shriram Krishnamurthi's Moby Scheme Compiler talk was particularly influential on this design. He described a similar (though simpler) system that he uses to make programming fun and interesting for middle school kids.

Hiveminder is waiting for your call

One of my favorite things about Hiveminder is the number and variety of systems it can talk to. Since we launched, we've wanted a way for you to be able to talk to Hiveminder.

We've just integrated Jott.com with Hiveminder. Jott is the "missing link" service that lets you dictate notes from your mobile phone. You can send email, add items to your calendar, and now you can put items on your Hiveminder todo list.

Wherever you are, whatever you're doing, Hiveminder is now just a phone call away:

1. Call 1-866-JOTT-123
2. Say "Hiveminder"
3. Then say your task. "Take out the garbage tomorrow"

Jott will transcribe your note, send it along to Hiveminder, and we'll create the task for you. You'll be able to listen to a recording of your note, so you don't need to worry about hard to understand words.

If you want, you can give all Jott tasks from your office phone the [work] tag. Just link your Jott account to a specific Hiveminder tasks by email address to automatically set tags, due dates and everything else we support in those [square brackets].

Setting up Hiveminder to work with Jott only takes a moment. Try it out today.

Hiveminder on Jabber

Many of us are enjoying our IM interface (I sure am!). Unfortunately, it has been AIM only. The most popular request for the IM bot has been "give us Jabber!". Today we've finally convinced HM Tasks to join the Jabbering ranks.

It takes only a few moments to set up your account for IM. On Jabber (and Google Talk) he is HMTasks@jabber.org. On AIM he is HMTasks.

After linking your Hiveminder account with your IM account, start out by sending todo.

We're also still adding new features to IM. If you're not using aliases yet, you're missing out. Aliases let you create your own shortcuts. For example, you can set up an alias h to expand to create [homework] [due tomorrow]. You can then type h read chapter 4 and it will do what you'd expect.

Our newest IM feature is filter. Filters let you focus on what needs to get done. For example, you can filter for "tag @work" and you'll only see tasks tagged with @work. Any new tasks will also get the @work tag. Using filters you can finally work with group tasks sanely on IM -- just filter group Spelling Bee Champions.

Enjoy!