RT-Extension-ChangeManagement - Change Management configuration for RT
Works with RT 5.
perl Makefile.PL
make
make install
May need root permissions
Add this line:
Plugin('RT::Extension::ChangeManagement');
make initdb
Only run this the first time you install this module. If you run this twice, you may end up with duplicate data in your database.
rm -rf /opt/rt5/var/mason_data/obj
To upgrade from an earlier version, see the instructions in the UPGRADING document.
This extension provides the configuration to implement a change management process in Request Tracker.
Organizations working to standardize internal processes for ISO or SOC compliance must have a standardized way to deploy and track changes to software, hardware, infrastructure, etc. This extension implements a change management system within RT, providing a framework for handling a variety of change types. It uses all core RT features, so everything can be modified as needed to align with your organization's practices and procedures. As-is, it provides a simple, fully functional implementation of an ITIL-like change management process.
To provide additional validation and required fields for different stages of the process, you can install RT::Extension::MandatoryOnTransition. An example configuration is provided in the sample configuration file in etc/ChangeManagement_Config.pm.
etc/ChangeManagement_Config.pm
We've provided a walkthrough video to demonstrate some of the functionality available in the change management extension.
After installing, you'll see a new queue called Change Management for tracking all of the incoming change requests. You can change the name to anything you like after installing. In a typical configuration, you will also want to assign an RT email address, like changes@example.com or crb@example.com (Change Review Team) to create tickets in this queue.
By default, Everyone can see the queue, create tickets, and view tickets. All users can also set custom fields on create, but only then. You can grant more rights if your change requestors need to update custom fields after the ticket is created.
The Change Management group has more rights to work on change tickets including taking ownership and approving or rejecting requests.
Some custom rights are available if you go to Admin > Queues, click on Change Management, then click Group Rights. The "Status changes" tab has specific rights to allow users to "Approve Requests" and "Implement Changes". By default, the Change Reviewer role can "Approve Requests" and the Change Implementor role can "Implement Changes". If this is too restrictive for your workflow, you can grant these to more users, possibly via a group.
The roles below are allow you to assign different users to parts of the change management process. In addition to clearly identifying who is responsible for parts of the process, these roles can be used to manage rights and notifications like email.
Person who reviews incoming change requests, and is responsible for approving or denying a change request.
Person who is responsible for implementing a change request.
Groups are included to make it easy to add users quickly and give them sufficient rights to interact with the Change Management queue.
The Change Management group gives a set of rights appropriate for staff who will work with chagne management tickets. It allows them to take tickets, comment, change custom fields, etc. You can refine all of these after you install the extension.
The Change Management lifecycle provides a set of common statuses. You can update this as needed to add or remove statuses and transitions.
Status given to a new change request. Indicates than a change has been requested and is awaiting approval.
For changes that are approved but not yet implemented.
An approved change that is in the process of being deployed.
The change has been partially deployed; it is either taking an unusually long time to complete, or part of the deployment succeeded while another part failed. Reasons as to why should be detailed in a comment.
The change has been deployed successfully.
The change failed to deploy. Reasons should be detailed in a comment.
This change was cancelled. Reasoning should be provided in a comment.
The change was rejected by the review team. Reasoning should be provided in a comment on the ticket.
Some common custom fields are provided to track additional information about changes. The provided custom fields can be modified as needed, to add or remove available values in dropdowns, for example.
You can also add more custom fields as needed. A %CustomFieldGroupings configuration is provided to group custom fields in a Change Management portlet. You can add new custom fields to this configuration to include them in this section.
%CustomFieldGroupings
Specifies the kind of change that is to be performed.
One of the three types of changes. The initial values are those outlined in ITIL:
A low risk, pre-authorized change that follows a repeatable process. This is the default for new tickets in the Change Management queue.
A change that must be performed ASAP, potentially bypassing approval steps.
Any change that doesn't fall into the other types.
A description of the steps necessary to perform a rollback of the proposed changes in the event that the deployment process is unsuccessful.
Date that the change was started. This is not the same as the normal Started date on the ticket. Started is set when the ticket is moved to an open status (such as approved); Change Started is when someone actually started implementing the change.
A scrip is provided to automatically set this when status changes to in progress or partially deployed.
Date that the change was successfully deployed. A scrip is provided to automatically set this when status changes to deployed.
A Change Management dashboard is installed with two saved searches included, one for upcoming changes and one for recently completed changes. These are useful for tracking change tickets and are also good examples of the types of saved searches and dashboards you can create for different participants in the change process.
Since this extension uses core RT features, it's easy for an RT administrator to customize various parts. Below are some ideas.
Some ideas of fields that could be added to the change management process might include:
Customer, Vendor, Internal. Dropdown.
Datacenter, customer site, etc. Text.
Steps needed to implement proposed change. Text.
Process for validating a change was deployed successfully. Text.
A description of what potential side effects of a proposed change might be, what could happen if the change goes awry, etc. Text.
Using RT::Extension::MandatoryOnTransition, any of the above fields can be made required upon a status change. For example, you may wish to make Implementation Steps, Validation Steps, and Impact Assessment required fields before a change request can be approved. See etc/ChangeManagement_Config.pm for a ready-to-use example with the out of the box configuration.
As an RT admin, you can go to Admin > Queues > Change Management, then click on Default Values in the submenu. From that page, you can set or change the default values for assigned custom fields.
Best Practical Solutions, LLC <modules@bestpractical.com>
All bugs should be reported via email to bug-RT-Extension-ChangeManagement@rt.cpan.org or via the web at rt.cpan.org.
This software is Copyright (c) 2022 by Best Practical Solutions, LLC.
This is free software, licensed under:
The GNU General Public License, Version 2, June 1991
To install RT::Extension::ChangeManagement, copy and paste the appropriate command in to your terminal.
cpanm
cpanm RT::Extension::ChangeManagement
CPAN shell
perl -MCPAN -e shell install RT::Extension::ChangeManagement
For more information on module installation, please visit the detailed CPAN module installation guide.