[Bps-public-commit] rt-extension-changemanagement branch master updated. d93a70225eb8d0a8447fd5fcffde6736af1b37e6
BPS Git Server
git at git.bestpractical.com
Fri Feb 25 21:30:28 UTC 2022
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "rt-extension-changemanagement".
The branch, master has been updated
via d93a70225eb8d0a8447fd5fcffde6736af1b37e6 (commit)
via 2b1c6f3d5035e73e680181e237ab9838300f3da6 (commit)
via 1853f1da3bedf1c33c29a699ae6da2215142556f (commit)
from 735c33cc595c102d0d7db942c04ce42138f499e6 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit d93a70225eb8d0a8447fd5fcffde6736af1b37e6
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Feb 25 16:30:20 2022 -0500
Update docs
diff --git a/README b/README
index bd4c716..9763bdd 100644
--- a/README
+++ b/README
@@ -1,14 +1,13 @@
NAME
- RT-Extension-ChangeManagement - Default Change Management configuration
- for RT
+ RT-Extension-ChangeManagement - Change Management configuration for RT
RT VERSION
Works with RT 5.
INSTALLATION
- "perl Makefile.PL"
- "make"
- "make install"
+ perl Makefile.PL
+ make
+ make install
May need root permissions
Edit your /opt/rt5/etc/RT_SiteConfig.pm
@@ -16,7 +15,7 @@ INSTALLATION
Plugin('RT::Extension::ChangeManagement');
- "make initdb"
+ 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.
@@ -26,55 +25,64 @@ INSTALLATION
Restart your webserver
DESCRIPTION
- Implements a minimalistic change management process within RT.
-
- It is often the case that businesses that have achieved some level of
- ISO or SOC compliance must have a standardized process by which to
- handle changes to software, hardware, infrastructure, etc. This
- extension implements a minimal change management system within RT. It
- provides a framework for handling a variety of change types, and leaves
- a lot of room for growth and flexibility with regards to your
- organization's practices and procedures. Out of the box, it resembles a
- scaled down version of an ITIL-like change management process.
-
- When combined with RT::Extension::MandatoryOnTransition, this extension
- can transform into a fully-featured change management system.
+ 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.
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 changes at example.com or
- crb at example.com (Change Review Team) to create tickets in this queue.
+ also want to assign an RT email address, like *changes at example.com* or
+ *crb at example.com* (Change Review Team) to create tickets in this queue.
Custom Roles
- Users can be assigned several roles that are part of the change
- management process:
+ 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. Can be assigned to a group.
+ approving or denying a change request.
Change Implementor
- Person who is responsible for implementing a change request. This
- role can be assigned to a group.
+ Person who is responsible for implementing a change request.
Groups
- The Change Management extension introduces one new group to RT: Change
- Review Team. Any members of this group are capable of approving or
- rejecting proposed changes in the Change Management queue.
+ Groups are included to make it easy to add users quickly and give them
+ sufficient rights to interact with the Change Management queue.
- Ticket Statuses
- Tickets in the change management queue can have any one of the following
- statuses:
+ 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 item. Indicates than a change has been
- requested and is awaiting approval.
+ Status given to a new change request. Indicates than a change has
+ been requested and is awaiting approval.
Approved
- Tickets with a status of Requested can be moved to Approved if the
- change has been accepted by the change review team.
+ For changes that are approved but not yet implemented.
In Progress
An approved change that is in the process of being deployed.
@@ -101,21 +109,21 @@ DESCRIPTION
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. Possible values
- include:
-
- Configuration Change
- OS Patching
- Firmware Update
- Software Update
- New Software Install
- Hardware Repair
- New Hardware Install
- Project Implementation
+ Specifies the kind of change that is to be performed.
Change Type
- One of the three types of change types outlined in ITIL:
+ 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.
@@ -135,50 +143,27 @@ DESCRIPTION
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
+ 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 implementation of the change. This is set automatically
- when a change ticket's status changes to in progress or partially
- deployed.
-
- Change Complete
- Date that the change was successfully deployed. This is set
- automatically when a change ticket's status changes to deployed.
+ actually started implementing the change.
- Actions
- Submit Request
- Changes the status of a ticket to requested.
+ A scrip is provided to automatically set this when status changes to in
+ progress or partially deployed.
- Approve Request
- Mark a change management request ticket as approved. Requires the Change
- Reviewer role.
-
- Deny Request
- Deny the change management request. Requires the Change Reviewer role.
-
- Start Deployment
- Changes the ticket status to in progress. Requires the Change
- Implementor role.
-
- Deployment Complete
- Marks the change request as deployed. Requires the Change Implementor
- role.
-
- Partially Deployed
- Marks the change request as partially deployed. Requires the Change
- Implementor role.
-
- Deployment Failed
- Changes the status of the request to failed. Requires the Change
- Implementor role.
+ Change Complete
+ Date that the change was successfully deployed. A scrip is provided to
+ automatically set this when status changes to deployed.
- Deployment Cancelled
- Cancels the change request (changes status to failed). Requires the
- Change Implementor role.
+ 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
- There are some ways RT::Extension::ChangeManagement can be customized to
- provide an even more robust change management system.
+ 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
@@ -209,26 +194,9 @@ CUSTOMIZING AND EXTENDING
of the box configuration.
Default Values for Custom Fields
- If you look at etc/initialdata in the plugin directory, you will find a
- section called @Final (unsurprisingly, it is the last section of
- configuration). There you will find some sample code and documentation
- for setting a default value for a custom field.
-
- The process basically boils down to:
-
- Load a named queue
- Load a custom field by name
- Set the default value for that custom field in that queue
-
- Approvals Queue
- If you have an established Change Review Board, your organization is
- likely dealing with a high volume of change requests. Separating
- requests into a second queue can make it quicker and easier to process,
- as new requests are not interspersed with other changes in various
- stages of completion.
-
- To separate change requests into a separate approvals queue, see the
- docs in the "Approvals" in Customizing guide.
+ 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 <modules at bestpractical.com>
diff --git a/lib/RT/Extension/ChangeManagement.pm b/lib/RT/Extension/ChangeManagement.pm
index 4788ed1..dc28836 100644
--- a/lib/RT/Extension/ChangeManagement.pm
+++ b/lib/RT/Extension/ChangeManagement.pm
@@ -6,7 +6,7 @@ our $VERSION = '0.01';
=head1 NAME
-RT-Extension-ChangeManagement - Default Change Management configuration for RT
+RT-Extension-ChangeManagement - Change Management configuration for RT
=head1 RT VERSION
@@ -45,66 +45,75 @@ you may end up with duplicate data in your database.
=head1 DESCRIPTION
-Implements a minimalistic change management process within RT.
+This extension provides the configuration to implement a change management
+process in L<Request Tracker|https://bestpractical.com/request-tracker>.
-It is often the case that businesses that have achieved some level of ISO or
-SOC compliance must have a standardized process by which to handle changes to
-software, hardware, infrastructure, etc. This extension implements a minimal
-change management system within RT. It provides a framework for handling a
-variety of change types, and leaves a lot of room for growth and flexibility
-with regards to your organization's practices and procedures. Out of the box,
-it resembles a scaled down version of an ITIL-like change management process.
+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.
-When combined with L<RT::Extension::MandatoryOnTransition>, this extension
-can transform into a fully-featured change management system.
+To provide additional validation and required fields for different stages of
+the process, you can install L<RT::Extension::MandatoryOnTransition>. An example
+configuration is provided in the sample configuration file in C<etc/ChangeManagement_Config.pm>.
=head2 Change Management Queue
After installing, you'll see a new queue called B<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 at example.com or crb at example.com (Change Review Team)
+email address, like I<changes at example.com> or I<crb at example.com> (Change Review Team)
to create tickets in this queue.
=head2 Custom Roles
-Users can be assigned several roles that are part of the change management process:
+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.
=over
=item Change Reviewer
Person who reviews incoming change requests, and is responsible for approving or
-denying a change request. Can be assigned to a group.
+denying a change request.
=item Change Implementor
-Person who is responsible for implementing a change request. This role can be assigned
-to a group.
+Person who is responsible for implementing a change request.
=back
=head2 Groups
-The Change Management extension introduces one new group to RT: Change Review Team.
-Any members of this group are capable of approving or rejecting proposed changes in
-the Change Management queue.
+Groups are included to make it easy to add users quickly and give
+them sufficient rights to interact with the Change Management queue.
-=head2 Ticket Statuses
+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.
-Tickets in the change management queue can have any one of the following statuses:
+=head2 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.
=over
=item Requested
-Status given to a new item. Indicates than a change has been requested and is
+Status given to a new change request. Indicates than a change has been requested and is
awaiting approval.
=item Approved
-Tickets with a status of Requested can be moved to Approved if the change has been
-accepted by the change review team.
+For changes that are approved but not yet implemented.
=item In Progress
@@ -137,33 +146,22 @@ comment on the ticket.
=head2 Custom Fields
-=head3 Change Category
-
-Specifies the kind of change that is to be performed. Possible values include:
-
-=over
-
-=item Configuration Change
-
-=item OS Patching
-
-=item Firmware Update
-
-=item Software Update
-
-=item New Software Install
+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.
-=item Hardware Repair
+You can also add more custom fields as needed. A C<%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.
-=item New Hardware Install
-
-=item Project Implementation
+=head3 Change Category
-=back
+Specifies the kind of change that is to be performed.
=head3 Change Type
-One of the three types of change types outlined in ITIL:
+One of the three types of changes. The initial values are those
+outlined in ITIL:
=over
@@ -190,54 +188,30 @@ changes in the event that the deployment process is unsuccessful.
=head3 Change Started
Date that the change was started. This is B<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 implementation
-of the change. This is set automatically when a change ticket's status changes to
+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.
=head3 Change Complete
-Date that the change was successfully deployed. This is set automatically when a
-change ticket's status changes to deployed.
-
-=head2 Actions
-
-=head3 Submit Request
-
-Changes the status of a ticket to requested.
-
-=head3 Approve Request
-
-Mark a change management request ticket as approved. Requires the Change Reviewer role.
-
-=head3 Deny Request
+Date that the change was successfully deployed. A scrip is provided to automatically
+set this when status changes to deployed.
-Deny the change management request. Requires the Change Reviewer role.
+=head2 Change Management Dashboard
-=head3 Start Deployment
-
-Changes the ticket status to in progress. Requires the Change Implementor role.
-
-=head3 Deployment Complete
-
-Marks the change request as deployed. Requires the Change Implementor role.
-
-=head3 Partially Deployed
-
-Marks the change request as partially deployed. Requires the Change Implementor role.
-
-=head3 Deployment Failed
-
-Changes the status of the request to failed. Requires the Change Implementor role.
-
-=head3 Deployment Cancelled
-
-Cancels the change request (changes status to failed). Requires the Change Implementor role.
+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.
=head1 CUSTOMIZING AND EXTENDING
-There are some ways RT::Extension::ChangeManagement can be customized to provide
-an even more robust change management system.
+Since this extension uses core RT features, it's easy for an RT administrator
+to customize various parts. Below are some ideas.
=head2 Additional Custom Fields
@@ -278,32 +252,9 @@ the out of the box configuration.
=head3 Default Values for Custom Fields
-If you look at F<etc/initialdata> in the plugin directory, you will find a section
-called C<@Final> (unsurprisingly, it is the last section of configuration).
-There you will find some sample code and documentation for setting a default value
-for a custom field.
-
-The process basically boils down to:
-
-=over
-
-=item Load a named queue
-
-=item Load a custom field by name
-
-=item Set the default value for that custom field in that queue
-
-=back
-
-=head2 Approvals Queue
-
-If you have an established Change Review Board, your organization is likely dealing
-with a high volume of change requests. Separating requests into a second queue can
-make it quicker and easier to process, as new requests are not interspersed with
-other changes in various stages of completion.
-
-To separate change requests into a separate approvals queue, see the docs in the
-L<Customizing/Approvals> guide.
+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.
=head1 AUTHOR
commit 2b1c6f3d5035e73e680181e237ab9838300f3da6
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Feb 25 16:29:43 2022 -0500
Update Module::Install
diff --git a/META.yml b/META.yml
index d256d74..c411df0 100644
--- a/META.yml
+++ b/META.yml
@@ -24,6 +24,6 @@ resources:
license: http://opensource.org/licenses/gpl-license.php
repository: https://github.com/bestpractical/rt-extension-changemanagement
version: '0.01'
-x_module_install_rtx_version: '0.42'
+x_module_install_rtx_version: '0.43'
x_requires_rt: 4.4.0
x_rt_too_new: 5.2.0
diff --git a/inc/Module/Install/RTx.pm b/inc/Module/Install/RTx.pm
index 2dd9489..2889ece 100644
--- a/inc/Module/Install/RTx.pm
+++ b/inc/Module/Install/RTx.pm
@@ -9,7 +9,7 @@ no warnings 'once';
use Term::ANSIColor qw(:constants);
use Module::Install::Base;
use base 'Module::Install::Base';
-our $VERSION = '0.42';
+our $VERSION = '0.43';
use FindBin;
use File::Glob ();
@@ -134,7 +134,7 @@ lexicons ::
if( $extra_args->{'remove_files'} ){
$self->include('Module::Install::RTx::Remove');
our @remove_files;
- eval { require "etc/upgrade/remove_files" }
+ eval { require "./etc/upgrade/remove_files" }
or print "No remove file located, no files to remove\n";
$remove_files = join ",", map {"q(\$(DESTDIR)$plugin_path/$name/$_)"} @remove_files;
}
commit 1853f1da3bedf1c33c29a699ae6da2215142556f
Author: Jim Brandt <jbrandt at bestpractical.com>
Date: Fri Feb 25 16:27:32 2022 -0500
Allow multiple users for custom roles
Single user custom roles really limit you to just one user,
so make it more flexible by default by allowing multiple
or groups.
Also remove the extra comment on setting default values in
initiadata code. Documentation is added on how to do this
via the RT web UI.
diff --git a/etc/initialdata b/etc/initialdata
index 7b46667..96c67ce 100644
--- a/etc/initialdata
+++ b/etc/initialdata
@@ -92,13 +92,11 @@ our @CustomRoles = (
Name => 'Change Reviewer',
Description => 'The person asked to review the change request',
ApplyTo => 'Change Management',
- MaxValues => 1,
},
{
Name => 'Change Implementor',
Description => 'The person asked to implement the change request',
ApplyTo => 'Change Management',
- MaxValues => 1,
},
);
@@ -205,16 +203,7 @@ our @Attributes = (
);
our @Final = sub {
- #
- # This is an example of how to make a custom field have a default value.
- # As most changes will be Standard, it makes sense to use it as the default.
- # You can similarly make other custom fields defined above have default values
- # by providing the name of the custom field to Load (like Change Type is below)
- # and changing Values to be the default value of the field (similar to how Standard
- # is set below).
- #
- # Remember that the custom field name and default values are case sensitive!
- #
+ # Set some default values for custom fields
my $queue_obj = RT::Queue->new(RT->SystemUser);
my $queue = 'Change Management';
$queue_obj->Load($queue);
-----------------------------------------------------------------------
Summary of changes:
META.yml | 2 +-
README | 180 ++++++++++++++---------------------
etc/initialdata | 13 +--
inc/Module/Install/RTx.pm | 4 +-
lib/RT/Extension/ChangeManagement.pm | 171 ++++++++++++---------------------
5 files changed, 139 insertions(+), 231 deletions(-)
hooks/post-receive
--
rt-extension-changemanagement
More information about the Bps-public-commit
mailing list