This page describes some of the extensions to the Request Tracker ticketing system, to add new features and support business processes, which I built while employed as a Linux system administrator and Linux architect.
| Key details | |
|---|---|
| Brief description: | Modules which extend the functionality of Request Tracker to meet specific business requirements. |
| Consumer: | IT Service Desk, IT change management, IT third-line teams, IT Testing Services, various Human Resources teams, Profit And Asset Protection, warehouse operational reporting team, various Logistics teams |
| Impact to consumer: |
|
| Technical features: |
|
| Technologies used: | HTML::Mason, Perl |
The company's original IT work tracking mechanism was a shared email inbox. This did not scale well. I installed and configured the Request Tracker tool, and over time expanded it to a clustered system with 8 application servers spread across 2 data centres with dual-primary database replication for front-end use, and multiple secondary databases for reporting and backup purposes.
Using Request Tracker's innovative callbacks mechanism, which allows customisation to be added without modifying the original software, I built around 100 local extensions over the years as business requirements evolved and other departments started using it for their own workflows.
Some of these extensions are described below.
Background ticket list
A component allowing ticket lists to be loaded in the background. This is used by several other extensions to provide a more responsive user interface.
Calendar view
A mechanism to view ticket search results as a calendar, using each ticket's Starts and Due dates to provide their position, and colour coding based on type and approval status. This is used by the change management team to generate an RFC calendar showing planned changes.
Delegated category fields with colour coding
Allow custom fields of the "select one value" type to be colour coded, and for the control of the list of possible values, and their colour codes, to be delegated to members of a specific RT group who do need any other special privileges.
Ticket checklists
Ticket owners can add checklists to tickets, with each checklist item having its own status (TODO, in progress, and done). Updating a checklist item's status is reflected in the ticket history.
Dashboard home page replacement
Request Tracker allows users to create their own dashboards, based on saved ticket searches and charts. This extension provides a way to replace the home page with a specific dashboard, and to set up group-based policies to ensure that teams all use the default view that is appropriate for them.
Ticket deferral and repeating tickets
Extend ticket lifecycles to include a "deferred" state, where a ticket disappears from standard searches until a specific future date - useful for reminders, and for other circumstances where a ticket can't be progressed until a particular time. This is combined with a "repeat" field parser, which allows a ticket to be given a "repeat" parameter such as "3 months" - when such a ticket is closed, a new duplicate ticket is automatically created and immediately deferred for the specified time. This is used to track work relating to regular maintenance.
Filter rule groups (message filtering)
A comprehensive message filtering mechanism, allowing tickets arriving in a queue to be altered, moved, and trigger notification emails, based on various attributes. Control of message filtering rules can be delegated to otherwise unprivileged operators on a per-queue basis.
Flag for review
A mechanism to allow operators to flag tickets for review by others in their team.
Google Translate integration
Integration of the Google Translate API with RT, so that parts of a page can be selected and translated, and a translation helper can be inserted at the bottom of comment/reply screens.
Knowledgebase
An indexed, categorised article repository, with content replicated across cluster nodes to ease the load on the central databases. This was developed instead of using RT's Articles system because the business processes required many features not present in RT's offering, including inline images, document revision review and approval steps, reader feedback, and visibility classification to allow articles to be restricted by team.
Mandatory fields
Queue managers can mark some custom fields as being mandatory, such that a ticket cannot change between specific states until the field is populated. For example, a ticket may be prevented from being transferred to another queue if it has not been categorised, or it may be prevented from being resolved if a resolution code has not been assigned.
Comment pinning
Allow a comment in a ticket to pinned (made "sticky"), so that a copy of it is always shown at the top of the history. The pinned comment can also be displayed in search results, and tickets can be matched based on whether they have a pinned comment. This is used by some teams to assist with work planning, by having operators occasionally add a summary of work done so far and pin it.
Privilege elevation
A mechanism to allow operators to temporarily add themselves to an RT group, typically one which has higher privileges assigned to it. Operators request privilege elevation, which must be approved by another team member. The request's purpose and associated ticket are documented. All actions taken by the operator during their elevated privilege session are discoverable in a session log, and there is a review mechanism to ensure that each session is reviewed by someone other than the session operator, for internal controls purposes. Session information is also exposed to the change management and internal controls teams in a specialised change management tool that I built outside of RT, via an API.
Consultation requests
Many teams needed the ability to ask for help on a ticket from another team, while retaining the original ticket - for example, the IT service desk first-line team may need to ask one or more third-line teams for troubleshooting assistance. This extension adds a new ticket action to allow the operator to quickly create a linked ticket to pass to another team. When the linked consultation ticket is viewed, it shows a preview of the original ticket's history in its metadata section for quick reference.
Response templates
When creating or responding to a ticket, the operator is presented with a list of templates to load a pre-prepared message from. The management of these templates can be delegated to RT groups without requiring administrative access. If a template contains placeholders, then loading the template will show an interstitial page prompting for values for each one. Special placeholders are also used to automatically draw information from other resources such as the number of tills in a particular store. Templates can also pre-populate watcher fields (Cc, AdminCc, etc) as well as all custom fields.
Template tickets
Queue administrators can designate particular tickets as templates, which are shown in a drop-down list at the top of the ticket creation form. The templates shown to an operator are tailored to the groups the operator belongs to. Creating a ticket from a ticket template effectively clones the whole ticket - which fields are included can be customised for each template. As a special case, particularly useful for data subject access requests where one item can generate work for several teams, child tickets can also be included in the template, such that creating a new ticket from that template will also create duplicates of all of that template's children.
Scheduled emails
Operators can be granted the rights to add scheduled emails to tickets, whereby messages that they prepare can be sent from that ticket on a schedule.
Show history on reply
This extension adds a small area next to the ticket reply/comment input box, in which the current ticket history is shown for reference.
Group membership synchronisation from Active Directory
Administrators can assign an Active Directory group name to an RT group, such that the membership of the RT group will automatically track the membership of the AD group. Also, the "privileged" flag in RT is managed by membership of a special AD group. This allows RT group memberships to be fully managed within Active Directory, once group rights have been set up in RT.
User email aliases
An extension to allow multiple email addresses to map to a single one, such that users may send email to RT from any one of several different email addresses, and it will always be mapped to their primary address rather than creating multiple watchers. A helper job runs from cron to inspect users' LDAP entries to find their alternate email addresses and automatically populate the mapping table.
Ticket finder view
An alternative to the RT dashboards, similar in many ways to a mail reader. A customisable list of saved searches is shown in a pane to the left, like a list of message folders; clicking on one loads the search results into the top half of the right pane, like a list of messages in a folder. Clicking any search result shows a preview of the ticket (metadata and first comment) in the bottom half, like a message preview. Buttons allow search results and tickets to be opened directly in their own windows or tabs.