Hello - I am looking for a way to utilize RT for a submission of a Change Request ticket with details of the CR listed in custom fileds. I also want to create a work flow for approval of CR. Can someone point me into right direction? Is this possible to do in RT?
Thank you so much!
nimda
Is the incoming email always in the same format? If so you can take a look at:
I also want to create a work flow for approval of CR. Can someone point me into right direction? Is this possible to do in RT?
There is an approvals workflow in RT already:
https://docs.bestpractical.com/rt/4.4.3/customizing/approvals.html
Or you can always try adding a custom right to the status transition to something like “resolved” so that only manager level employees can set status to resolved
We do our (ITIL-esque) change requests using RT with custom fields, and custom forms. I wrote a blog post about it that you may (or may not!) find useful.
We’ve been using it for well over a year now and seems to work OK (modulo some people not getting the idea of different change closure statuses, but that’s not RT’s fault!).
THANK YOU! Great article!
Very nice. We are looking at doing something similar to closeout a legacy app. Would it be possible to see the configuration for your custom screens/menu?
Regards,
Ken
The menu items are just run from a local callback on Elements/Tabs. It has a load of very local specific group membership tests. Not everyone who uses RT here gets to see the changes stuff - it’s just for IT staff. They also need to be in a group with access to a queue that uses the custom change lifecycle we created and even then some bits are only shown to admins and change managers. So for example one test is to allow the system admin to see the changes menu:
$Group->LoadSystemInternalGroup('Admin');
if($Group->HasMemberRecursively($session{'CurrentUser'}->Id)) {
$showChanges = 1;
}
Once a valid group membership has set the variable $showChanges to true something like this runs:
if($showChanges) {
my $changes = Menu->child( 'changes' );
if(!$changes) {
$changes = Menu->child( changes =>
title => loc('Changes'),
description => loc('Change management submission forms'),
path => loc('/Changes'),
);
}
my $documents = $changes->child( changes =>
title => loc('Documentation'),
description => loc('Homepage for Service Management documentation'),
path => 'https://our.documentation.server.url/documentation.html',
target => "_blank"
);
$changes->child( normal =>
title => loc('Normal change'),
description => loc('Normal change process (approval via line management & CAB)'),
path => '/Changes/Normal.html'
);
$changes->child( preapproved =>
title => loc('Pre-approved change'),
description => loc('Pre-approved change process'),
path => '/Changes/PreApproved.html'
);
$changes->child( emergency =>
title => loc('Emergency change'),
description => loc('Emergency change process (approval via SLT)'),
path => '/Changes/Emergency.html'
);
$changes->child( mychanges =>
title => loc('My Changes'),
description => loc('Changes I\'m working on'),
path => '/Changes/MyChanges.html'
);
}
There’s actually loads more to in our live menu than that as we also have things like “canned” change requests and a bunch more documentation (quick start guides, policies, etc), but this gives you the basic idea. Canned changes are links to one of the /Changes Mason links shown above that additionally have a set of parameters passed in as well. These deal with changes that are put in regularly with similar details so we give users a partially completed change request template - for example network switch upgrades where its just the location and date/time that change usually. That saves people having to cut-n-paste the same details each time they generate a change request.
The actual user interface behind /Changes/Normal.html, /Changes/Emergency.html and /Changes/Pre-approved.html are custom Mason elements that generate the forms we require and validates the data the user enters. That’s pretty specific to our change process and local resources, and not something I’d want to share without doing a lot of sanitization! It’s also quite complex. We modelled the workflow that the change management folk wanted and then implemented that in the Perl code that drives the Mason elements. Although you can see that we separate out “normal”, “emergency” and “pre-approved” changes in the menus and links, the same Mason code implements all of them - its one Mason file symlinked to the other two names in /opt/rt4/local/html/Changes. That’s because a lot of the process and validation is shared between the three change types and it was easier to do it all in one place and ensure that we didn’t get things out of sync when the change process changes.
We’ve also added the option to allow certain people to upload spreadsheets of pre-approved change requests. This is handy when an IT project needs to submit loads of individual changes that are all “pre-approved” types (so don’t need to go to a Change Approval Board meeting). For example updating large number of Wifi access points or re-imaging different student PC labs every summer. Indeed the ability to upload spreadsheets with bulk ticket information is proving to be popular enough that we’ve got a prototype uploader for normal, non-change tickets awaiting testing and then (hopefully) deployment.
Incidentally one upside/downside of our set up (depending on how you look at it) is that people can still access the change tickets via the normal RT tools, even though we don’t encourage that. Sometimes that’s really handy to put in “odd” things that these custom constrained change request forms don’t support (such as adding Cc’s, etc) but it does mean that people can accidentally stuff up their own change requests sometimes! Luckily not terribly often, and there is the transaction history so an admin can go in and put it right for them (and then try to work out how to stop it from happening again!).
Thank you for the nice overview of your setup.
Regards,
Ken