RT 4.0.12 released

It's my pleasure to announce RT 4.0.12 is now available for download.

This release of RT repairs a regression in 4.0.11. If you use the Rich Text Editor, the red background on Reply was missing due to the update of CKEditor to support IE10. It also includes a database upgrade, so please make sure to run 'make upgrade-database'.

Features

• Date and DateTime Custom Fields now have the same 'smart' date parsing that core RT date fields have.
• Improved logging when the sending of a Correspond or Comment fails.
• The Quick Search preferences page now has Select/Clear All buttons.
• Unprivileged users can now change Language and Time Zone.
• Warn MySQL users if their max_allowed_packet is dangerously low.

Bugfixes

• Repair 4.0.11 regression where red background on Reply with the RichText Editor was lost.
• Quiet warnings in the verbose user format.
• Allow changing the case of a Group's name (prevented by earlier code stopping you from having two groups with the same name).
• Allow changing the case of a Class's name.
• Avoid warnings when using empty Templates.
• Update our InnoDB checks for MySQL 5.6 compatibility.
• Clarification of when SetOutgoingMailFrom and OverrideOutgoingMailFrom are available.
• Improve layout of collection lists in IE.
• Fix Attach more files button in Self Service.
• Set caching headers on autocomplete endpoints.
• Restore and improve prematurely deleted documentation for DontSearchFileAttachments.
• Correct the encoding of Dashboard email Subject headers.
• Fix the default roles on User->WatchedQueues.
• Document the need to grant SeeCustomField in UPGRADING-3.4.
• Nudge menus below the shadows in aileron.
• Fix missing headers and a syntax error in the /REST/1.0/attachment/NN endpoint.

Localization

• Improve the display of numbers when using the French localization.
• Built in components and searches (such as Bookmarked Tickets) are now localizable.
• Use PostgreSQL error codes in the full-text-indexer instead of matching on error messages that may be in a non-english language.
• Localize 'Dashboard' during creation.
• Mark 'Modify this user' as localizable.

Developer

• Test can now be run against a remote DB server.
• Install etc/upgrade to make some rt-setup-database actions easier without requiring access to the install directory.
• RT_TEST_PARALLEL_NUM controls the -j param in make parallel-test
• Work around a git bug in git archive when packaging releases. This caused the third party sources to bloat the 4.0.11 tarball.
• Fix examples in the CreateTickets documentation.
• RT Ticket types (ticket, approval, reminder) are now always forced to lower case.
• Allow the use of 'NOT IN' in Limits (assuming a new enough DBIx::SearchBuilder).

A complete changelog is available from git by running:

git log rt-4.0.11..rt-4.0.12

or viewing Github's comparison.

On our security policies

We take software security very seriously at Best Practical. Weregularly conduct audits of our own code and make security releases (including patches for all supported previous versions) for the vulnerabilties that we find. We want to ensure that the software we produce — which is often used to track security incidents — is not itself the cause of any.

We thus wish to make clear that the recent claim of a SQL injection vulnerability (since retracted) in RT is incorrect. We were notified via email on the 10th, and immediately examined the report. Within a few hours we had verified that the claimed exploit did not function according to the author's claims, and replied to the reporter accordingly, asking for further information.

Best Practical believes in responsible disclosure; namely, that vulnerabilities should be reported to the vendor privately, and then a timeline should be jointly established upon which the vulnerability will be made public. This allows sufficient time to examine the problem, come to a minimally-invasive solution which addresses the root cause, and prepare patches for all relevant supported versions of RT — while balancing this against the threat that the vulnerability is already being exploited in the wild. Past security researchers who have reported potential vulnerabilities have been excellent about discussing timeframes for public release of the weaknesses they have found.

Unfortunately, the author of the above report did not wait for a response from us before publishing his mistaken findings. Publishing unverified vulnerabilities can easily cause unnecessary CVEs (CVE-2013-3525 was assigned to this one) and confusion for vendors and users of the software. In this case, the Debian security team, who we've worked with in the past, picked up the report and contacted us to verify it. At that point in time, we decided to publish this notice.

If you ever believe you have found a vulnerability in our software, please report it to security@bestpractical.com so we can work together to verify it and resolve it in a timely manner. We also appreciate if you provide a PGP public key, so we can encrypt any security-sensitive communication. This information is, as always, available from bestpractical.com/security/

RT 4.0.11 Released

I'm happy to announce that RT 4.0.11, the latest stable release, is now available.

This release of RT contains two large updates.

The WYSIWYG editor (CKEditor) used on ticket creation and reply pages has been updated to address numerous reports of breakages when using IE 10. It also includes fixes for many other browsers. You can read more about the included changes. We are shipping 3.6.6.1, upgraded from 3.4.1.

If you use RT with mod_perl and have not updated from SetHandler perl-script to SetHandler modperl, RT will now refuse to start. You can read more about mod_perl configuration here.

A complete changelog is available

Scheduled Ticket Creation in RT

Do you have tasks that you track in RT and happen on a regular schedule? Maybe you want someone to review all the newly created articles once every two weeks or once each month you need people to update the hardware inventory. With RT::Extension::RepeatTicket, you can now you can set up that schedule and automatically create the tickets in RT.

After you install and activate the extension, a new Recurrence portlet appears on existing tickets and for newly created tickets. You can use this to enable a recurrence based on the current ticket and set a schedule for creating future tickets in the recurrence. The scheduling options are similar to what you see in most calendaring applications. The dates you pick become the due dates for the created tickets.

In addition to the scheduling details, you'll see some other options including ticket lead time and concurrent active tickets. The lead time value allows you to control how much advanced notice the ticket owner should get. People don't want a whole list of tickets in their active ticket list, but they also don't want to get a task the day it is due. The lead time sets the number of days before the due date the ticket will be created.

On many tasks you won't want people to miss the due date, but if they do, you don't also need them to then do the task twice to catch up. You need them to do it and resolve the ticket (and try to do it by the due date next time). The concurrent active tickets value helps you avoid piling on more tickets for a recurrence if previous tickets haven't been resolved.

You can also stack tasks end-to-end and create the next new ticket some time interval after the previous task is resolved. Just select "Create new task X days after each task is completed".

Much like a meeting, sometimes you need to update the criteria for the recurrence. Maybe you need the due date to be on Tuesdays rather than Thursdays. The recurrence data itself is stored on the original ticket you use to create the recurrence. Each ticket automatically created from the recurrence has a custom field called Original Ticket. This stores the ticket id of the ticket with the recurrence data. To change the recurrence, just click the id link back to the original ticket, even if it's resolved, and update the details. The new schedule will be applied for all new tickets in the recurrence.

As part of the configuration, you'll set up a cron job to run the rt-repeat-ticket script provided with the extension. By default, the script runs for the current day, creating any necessary new tickets based on the configured recurrences. However, you can also pass it a date to run for. This can be handy if you want to experiment with scheduling something a several months out but don't want to wait that long to test the recurrence settings.

This extension has a lot of options and it can be a little tricky getting recurrences set up to create tickets just the way you want. But once you understand the various options, we hope you'll find it does what you need.

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

Keeping Track of Extra Email CCs

Many people work with RT exclusively via email. During an email thread attached to a ticket, they might CC someone on a response because they want them to see what's being discussed, answer a question, etc. The new person will see that email, but if they aren't added as a Watcher of some sort on the RT ticket, they'll miss other correspondence.

We've released a new extension we've found handy in detecting when this happens so you can add people to a ticket to keep them in the loop. RT::Extension::NonWatcherRecipients, despite the big name, is a simple extension that detects extra email addresses and notifies you about them. The typical recipients are the AdminCcs on the ticket, since they can go into RT and update the Watchers, so it installs a new template called "NonWatcherRecipients Admin Correspondence". You can select this as a replacement for the standard "Admin Correspondence" template and see this sort of message when extra emails are found:

------------------------------------------------------------------------
From: "A User" <a-user@example.com>
The following people received a copy of this email but are not on the ticket.
You may want to add them before replying:
https://YourRT.com/Ticket/ModifyPeople.html?id=12345
Cc: "Non Watcher" <non-watcher@example.com>
------------------------------------------------------------------------

The link takes you to the People page for that ticket so you can easily add the new people.

If you have customized templates you can drop in the following:

{ RT::Extension::NonWatcherRecipients->FindRecipients(
Transaction => $Transaction, Ticket => $Ticket ) }

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

New RT extension for making fields mandatory on status transitions

We're happy to announce the release of RT::Extension::MandatoryOnTransition, an extension that allows you to make fields required in RT before a ticket can move to a different status.

This is an often-requested feature, typically in the form of "we want to require a subject on create," "we want to require users to enter time before they can resolve a ticket" or "we want to require users to enter a value for this custom field before they resolve." There have been various solutions for this feature, most focused on specific cases.

As we considered this feature, we also thought about the flexibility of lifecycles, and wanted to create something that would apply to any transition our users might come up with, not just the stock statuses. The result is RT::Extension::MandatoryOnTransition which, as the title suggests, allows you to make fields mandatory for any transition.

Once installed, you can set mandatory fields and transitions with some configuration:

Set( %MandatoryOnTransition,
'QueueName' => {
'from -> to' => [ 'BasicField', 'CF.MyField', ],
},
);

You can limit to one queue or apply the rule globally with a '*'. The inner hash defines the transition on which you want to apply the rule. The entries should map to entries in the lifecycle for that queue. If you haven't configured a custom lifecycle, you can find the default RT lifecycle configuration in your etc/RT_Config.pm file.

If you put a condition on resolve, the fields you define, including custom fields, are displayed on the Resolve page to allow users to easily enter a value. However, the extension currently doesn't apply the restrictions on the "Quick" actions like "Quick Resolve." If you want to enforce the required fields, you'll need to disable quick actions on those transitions in your lifecycle config (see the lifecycles documentation for details). We may add support for quick actions in the future.

We hope you find this extension useful. Bug reports or comments are welcome at bug-RT-Extension-MandatoryOnTransition@rt.cpan.org, pull requests via github.

Security vulnerability in Perl

This is a notification of a security vulnerability, not in RT, but inperl itself. That vulnerability, CVE-2013-1667, affects all production versions of perl from 5.8.2 to 5.16.x.

From perl5-porters:

In order to prevent an algorithmic complexity attack against its
hashing mechanism, perl will sometimes recalculate keys and
redistribute the contents of a hash.  This mechanism has made perl
robust against attacks that have been demonstrated against other
systems.
Research by Yves Orton has recently uncovered a flaw in the
rehashing code which can result in pathological behavior.  This flaw
could be exploited to carry out a denial of service attack against
code that uses arbitrary user input as hash keys.

Vendors, including RedHat, Debian, and Ubuntu, were informed of this problem two weeks ago. Debian has pushed updated packages, and others are expected to do so soon. We encourage you to take these updates as soon as they are available.

We are aware that taking updated versions of some vendor perl packages (particularly with older releases of RedHat) may downgrade some modules that RT requires to run, causing breakages when RT is restarted. This is particularly known to be an issue with Scalar::Util, Sys::Syslog, and File::Temp.

For this reason, we suggest re-running rt-test-dependencies after you upgrade perl, to ensure that this has not occured. You can do this via running /opt/rt4/bin/rt-test-dependencies, and passing it one of --with-mysql, --with-pg, or --with-oracle, as well as --with-fastcgi or --with-modperl2 as suits your current deployment. If unmet dependencies are found, you should immediately upgrade them; this can be done by re-running rt-test-dependencies with the additional --install option.

The vendor upgrades of perl may not be sufficient if you are running a locally-compiled version of perl. You can determine if this is the case by examining the first line of /opt/rt4/bin/rt (or /opt/rt3/bin/rt). If that line contains:

#!/usr/bin/perl

...then you are running the vendor-supplied version of perl, and need take no further steps. Otherwise, you will need to upgrade your locally installed perl, or re-install it after applying security patches. Perl 5.16.3 and 5.14.4 have now been released, and we strongly we recommend upgrading to those.

If you need help resolving this issue, please contact us at sales@bestpractical.com for more information.

RT Training in Amsterdam — March 20th & 21st, 2013

Best Practical Solutions provides unparalleled instruction in how to get the most out of RT.

Our first training session of 2013 will be held in Amsterdam on March 20th and 21st. 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 it to this training session, feel free to drop us a line to suggest locations for the future.

This training will introduce you to the new features in RT4 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.

Pricing and Payment

The cost of the class includes training materials, a continental breakfast and an afternoon snack. Please note that lunch will not be provided.

Single Day - USD 995
Both Days - USD 1495 (25% savings)

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.

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

RT 3.8.16 Released

I'm happy to announce that RT 3.8.16, the latest maintenance release, is now available.

Recent support for partitioned GnuPG emails introduced a deadlock situation for large QP/Base64 emails with GnuPG enabled. In addition, this release resolves a number of issues running the test suite on newer versions of perl.

RT::Extension::Announce Released

We recently released RT::Extension::Announce which gives you an easy way to insert announcements on your RT homepage so all users can see the message. You may want to display a banner during maintenance or maybe an unscheduled outage to make sure the people fielding customer tickets know that something is going on.

The messages are set and managed in a dedicated queue, created when you install the module. This allows you to manage who can post announcements using permissions on the queue. You can also show messages only to select groups if you don't need to notify everyone.

More details are available in the RT::Extension::Announce documentation. Bugs or comments welcome at bug-RT-Extension-Announce@rt.cpan.org, pull requests via github.