• Upgrading to 4.0
  • Web interface
    • Menus
    • Incidents and Investigations
    • MaxInlineBody
  • Queues
  • Countermeasures
  • Constituencies
    • Changes to constituencies
    • Web interface
    • Ticket linking
    • Setting constituency based on email headers
  • Rights
    • ForwardMessage

Upgrading to 4.0

The following describes some of the key components of the upgrade to RTIR 4.0 from RTIR 3.2. The other UPGRADING documents contain details for previous versions.

Web interface

Menus

When working inside RTIR, RT's menus are moved under the RT heading and RTIR's menus are expanded. We'd greatly appreciate your suggestions for filling out RTIR's menus with additional useful functionality.

Incidents and Investigations

It is no longer possible to launch an investigation on the incident creation page. Users will find the 'Launch Investigation' menu item missing when creating an incident. This removal is a result of the flexibility granted by the constituency rewrite in RTIR 4.0.

MaxInlineBody

The default value for the $MaxInlineBody config has changed from 0 (meaning unlimited) to 25kb. You may wish to adjust this if you were relying on RTIR's default.

Queues

It is now possible to have multiple incident report, incident, investigation and countermeasure queues in RTIR. RTIR uses a queue's lifecycle to determine what kind of queue it is, rather than its name. This functionality is very much in its infancy and we welcome your feedback.

Countermeasures

The Blocks queue was renamed to Countermeasures to indicate it is more generic than just network blocks. The normal RTIR upgrade process handles most of the renaming process, but you may need to adjust some of your configuration and customizations.

The "blocks" lifecycle has been renamed to "countermeasures". If you copied the RTIR lifecycle config, regardless of whether you customized it, you'll need to rename the "blocks" lifecycle to "countermeasures" in your config.

If you use RT_Config option RTIR_DisableBlocksQueue, please update your config to instead set that option by its new name: RTIR_DisableCountermeasures.

Similarly if you use RT_Config option RTIR_BlockAproveActionRegexp, please update its name to RTIR_CountermeasureApproveActionRegexp (beware the typo fix in the word "Approve").

If you set the RTIR_IncidentChildren config option, you'll need to adjust the key "Block" to "Countermeasure" (note: not "Countermeasures").

If you have any custom code that deals with Blocks queues by name, you'll need to update it.

Constituencies

Changes to constituencies

RTIR 4.0 features a major overhaul of the constituency system. The standard upgrade procedure should migrate old constituencies to the new system.

The new constituency system replaces the ticket-level 'Constituency' custom field with a queue-level 'RTIR Constituency' custom field. Each RTIR constituency now consists of four or more RT queues. Tickets associated with a given consituency will be placed in consistency-specific queues, rather than in the generic RTIR queues. This has the advantage of being much faster, much simpler and much easier to understand. In essence, we've replaced an older hack with a standard RT feature.

What makes an RTIR queue an RTIR queue is now that its lifecycle is set to one of the four RTIR lifecycles: 'investigations',' incident_reports', 'incidents' and 'countermeasures'. If it has a value for the 'RTIR Constituency' custom field, it will also be associated with that constituency.

Unlike earlier releases of RTIR, ACLS, Scrips, Custom Fields and queue configuration for constituency-specific queues is now drawn explicitly from those queues.

Web interface

If a user has permissions to work with multiple constituencies, it is now possible to limit RTIR's web interface to a single constituency by clicking a link from the Work with constituency box on the RTIR homepage. They can also go directly to /RTIR/c/ConstituencyName.

Ticket linking

The $RTIR_StrictConstituencyLinking option replaces the old $_RTIR_Constituency_Propagation configuration option. $RTIR_StrictConstituencyLinking is a simple boolean which implements the most common behaviors of $_RTIR_Constituency_Propagation.

If $RTIR_StrictConstituencyLinking is set to 1, any attempt to link RTIR tickets across constituencies will result in an error.

If $RTIR_StrictConstituencyLinking is set to 0, RTIR will allow users to link tickets across multiple constituencies.

Setting constituency based on email headers

RTIR 3.2 allowed sites to set ticket constituencies based on the X-RT-Mail-Extension message header. As RTIR now supports the features of 'regular' RT queues for constituencies, using message headers to set RTIR constituencies is no longer available.

Rights

ForwardMessage

DutyTeams now have the ForwardMessage right by default.

← Back to index