-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathREADME
239 lines (183 loc) · 9.06 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
NAME
RT-Extension-ChangeManagement - Change Management configuration for RT
RT VERSION
Works with RT 5.
INSTALLATION
perl Makefile.PL
make
make install
May need root permissions
Edit your /opt/rt5/etc/RT_SiteConfig.pm
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.
Clear your mason cache
rm -rf /opt/rt5/var/mason_data/obj
Restart your webserver
UPGRADING
To upgrade from an earlier version, see the instructions in the
UPGRADING document.
DESCRIPTION
This extension provides the configuration to implement a change
management process in Request Tracker
<https://bestpractical.com/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.
We've provided a walkthrough video <https://youtu.be/uQEEf7SGlkg> to
demonstrate some of the functionality available in the change management
extension.
Change Management Queue
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 *[email protected]* or
*[email protected]* (Change Review Team) to create tickets in this queue.
Rights
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.
Custom Roles
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.
Change Reviewer
Person who reviews incoming change requests, and is responsible for
approving or denying a change request.
Change Implementor
Person who is responsible for implementing a change request.
Groups
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.
Change Management Lifecycle
The Change Management lifecycle provides a set of common statuses. You
can update this as needed to add or remove statuses and transitions.
Requested
Status given to a new change request. Indicates than a change has
been requested and is awaiting approval.
Approved
For changes that are approved but not yet implemented.
In Progress
An approved change that is in the process of being deployed.
Partially 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.
Deployed
The change has been deployed successfully.
Failed
The change failed to deploy. Reasons should be detailed in a
comment.
Cancelled
This change was cancelled. Reasoning should be provided in a
comment.
Rejected
The change was rejected by the review team. Reasoning should be
provided in a comment on the ticket.
Custom Fields
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.
Change Category
Specifies the kind of change that is to be performed.
Change Type
One of the three types of changes. The initial values are those outlined
in ITIL:
Standard
A low risk, pre-authorized change that follows a repeatable process.
This is the default for new tickets in the Change Management queue.
Emergency
A change that must be performed ASAP, potentially bypassing approval
steps.
Normal
Any change that doesn't fall into the other types.
Rollback Plan
A description of the steps necessary to perform a rollback of the
proposed changes in the event that the deployment process is
unsuccessful.
Change Started
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.
Change Complete
Date that the change was successfully deployed. A scrip is provided to
automatically set this when status changes to deployed.
Change Management Dashboard
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.
CUSTOMIZING AND EXTENDING
Since this extension uses core RT features, it's easy for an RT
administrator to customize various parts. Below are some ideas.
Additional Custom Fields
Some ideas of fields that could be added to the change management
process might include:
Change Origin
Customer, Vendor, Internal. Dropdown.
Location
Datacenter, customer site, etc. Text.
Implementation Steps
Steps needed to implement proposed change. Text.
Validation Steps
Process for validating a change was deployed successfully. Text.
Impact Assessment
A description of what potential side effects of a proposed change
might be, what could happen if the change goes awry, etc. Text.
Making Custom Fields Required
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.
Default Values for Custom Fields
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.
AUTHOR
Best Practical Solutions, LLC <[email protected]>
All bugs should be reported via email to
or via the web at
http://rt.cpan.org/Public/Dist/Display.html?Name=RT-Extension-ChangeManagement
LICENSE AND COPYRIGHT
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