Change control

Hi Folks,
Has anyone come up with any good methodologies for change control
of an RT installation? Many of the components are database records
that don’t seem amenable to CVS control, scrips and templates as well
as custom field definitions and queue setups. We’d like to have a record
of what changed when and by whom, and be able to reconstruct the
state of the system or back out a change. Even an audit record of what
changed would be better than nothing, even if it can’t be used directly
for backing out a change. Has anyone tackled this?
Best,
-Chuck Boeheim
Stanford Linear Accelerator Center

smime.p7s (3.25 KB)

Has anyone come up with any good methodologies for change control
of an RT installation? Many of the components are database records
that don’t seem amenable to CVS control, scrips and templates as well
as custom field definitions and queue setups. We’d like to have a
record
of what changed when and by whom, and be able to reconstruct the
state of the system or back out a change. Even an audit record of
what
changed would be better than nothing, even if it can’t be used
directly
for backing out a change. Has anyone tackled this?

Great question, and I’d love to hear what people are doing… sounds
like a page dying to be in the wiki!

I thought about just keeping a $RTHOME/install-notes.txt about what I
did, components / add ons / hacks I put in place… it makes me very
afraid to upgrade to current (and im only 0.0.1 back!)

duncan

I’d venture that a good backup and then perhaps comitting the sql backup into Subversion or CVS is one way to control those elements. In practice we normally commit the production base install for the files and also our local customizations into Subversion for control and tracking. No reason why you couldn’t script a regular dump of the relevant tables and then commit those to one of the branches…

Michael Eraña, CISSP
CTO
PC Network, Inc.

|=> -----Original Message-----
|=> From: rt-users-bounces@lists.bestpractical.com
|=> [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
|=> Of Chuck Boeheim
|=> Sent: Tuesday, March 14, 2006 12:04 PM
|=> To: rt-users@lists.bestpractical.com
|=> Subject: [rt-users] Change control
|=>
|=> Hi Folks,
|=> Has anyone come up with any good methodologies for change
|=> control of an RT installation? Many of the components are
|=> database records that don’t seem amenable to CVS control,
|=> scrips and templates as well as custom field definitions
|=> and queue setups. We’d like to have a record of what
|=> changed when and by whom, and be able to reconstruct the
|=> state of the system or back out a change. Even an audit
|=> record of what changed would be better than nothing, even
|=> if it can’t be used directly for backing out a change. Has
|=> anyone tackled this?
|=> Best,
|=> -Chuck Boeheim
|=> Stanford Linear Accelerator Center
|=>

Even an audit record of what
changed would be better than nothing, even if it can’t be used directly
for backing out a change. Has anyone tackled this?

The quick and dirty way to do this is simply to turn on SQL Statement
loggingon the db.

Jesse

Chuck,

We are attempting to do just that here at LBNL. The "APPROVAL" setup 

in RT does not seem to create the kind of audit trail we would like. We
would like a request to keep it’s number, that way every stage, from
approval for work to approval for Acceptance testing to approval for
installation is in history for the same request numer and therefore
easier to track. If RT would allow for a few more options in the
drop-down selection for staus (like “pending approvel”, “approved for
work”, “approved for QA”, “approved for inplementation”), we could write
scrips to move a request from a particular approval queue to a work
queue and back to another approval queue (for QA as an example) and on
to implemntation. That way queues can be used as steps in a work flow
and the history of a request remains intact with the same number, going
from queue to queue in the workflow. Well, anyway, that’s one idea we
have. It may require scrips that modify the status field temporarily
until the request can be moved to another queue and modify the status
again. We don’t know yet because we are currently in the process of
playing with this design idea, but at least it is an idea that could
work, provided RT can handle the change to the status field.

Kenn

Chuck Boeheim wrote:

You can add new status values to RT. Check out RT_SiteConfig.pm
near the bottom, where it defines @ActiveStatus and @InactiveStatus

But that’s not the same question as tracking changes to RT, is it?
Unless you have a procedure of not changing RT until you’ve
created a (approved) ticket that says “I’m about to make the
following change to RT”.

As to that, what if you put triggers on the relevant db tables,
so as to record any change in a separate audit table?

 bobg

Bob,

Good point. In fact, as we "evolve" our approval work-flow design, 

we are doing something similar. We have added a couple new "status"
values and use those in conjuction with some new scrips that trigger off
actions (like change Queue) to communicate to the requestor that the
initial request has been approved for work and has been moved to the
Queue where the work will be done. This keeps all the history with the
request and puts a BIG smile on our auditors faces. Of course, we like
having the ability to follow the work-flow ourselves and having an
approval Queue for the requestors keeps our technical people from
wasting a lot of time running down problems that aren’t technical (like
permissions or incomplete training, etc.). We are just starting out with
this flow design and I’m sure we’ll have to make a few adjustments, but
right now it seems to be working really well in test and we’re hoping to
get the final model working, debugged and into production soon (of
course we’ll have to do a lot of maintenance configuration, but well
worth it). Thanks for your input.

Kenn

Bob Goldstein wrote:

Hi Ken,On Tuesday 14 March 2006 19:56, Ken Crocker wrote:

We are attempting to do just that here at LBNL. The "APPROVAL" setup

in RT does not seem to create the kind of audit trail we would like. We
would like a request to keep it’s number, that way every stage, from
approval for work to approval for Acceptance testing to approval for
installation is in history for the same request numer and therefore
easier to track. If RT would allow for a few more options in the
drop-down selection for staus (like “pending approvel”, “approved for
work”, “approved for QA”, “approved for inplementation”), we could write
scrips to move a request from a particular approval queue to a work
queue and back to another approval queue (for QA as an example) and on
to implemntation. That way queues can be used as steps in a work flow
and the history of a request remains intact with the same number, going
from queue to queue in the workflow.

I managed the different approval stages with one queue for each stage,
moving the ticket accordingly.
For convenience, i used the callback in /Elements/RT__Ticket/ColumnMap to
display the actual stage in the status field on the ‘RT at a glance’ page.
Approval ist requested with a CustomField i created therefor, the stage
status is saved in a hidden CustomField. You may also count the existing
(resolved) dependencies for a ticket within the workflow, but the hidden
custom field works more smoothly, i think.
Just make sure, your co-workers aren’t able to resolve tickets in
between :slight_smile:

regards, andreas

Andreas,

Good comment on users approving between stages. We have one Approval 

Queue (visable to the users) that handles requests for several Queses
where the work is done. The priviledges are set so the user/requestor
can always see their request, regardless of Queue, but they can only
create tickets in the Approval Queue. After review and approval, then
the request is moved to the working Queue and at that time we have a
script that kicks in for that move, which set stautses the way we want.
We don’t use any of the default global scripts for the Approval Queues.
We think we have more control that way and the Tickets are more visable
to the user as well. But hey, good ideas. I like exchanging thoughts and
philosophies on work-flow and stuff. Thanks for your ideas.

Kenn

Andreas Putzo wrote:

Hi.

I have a customer who wants to tailor his template verbiage based upon
if the ticket is New, Updated, or Resolved … I was originally just
going by the $Ticket->Status in the template, but they have a funny
habit of creating the ticket with the “open” status. Obviously, this
throws off the template.

I have been trying to figure out if I can access the previous value of
the $Ticket->Status, but so far have struck out. I’ve played with
trying to get the list of transactions for the ticket, but if it’s in
there, I can’t get the right magic to work.

Currently, they are maintaining 3 different scrips so they can use 3
slightly different templates … that seems sort of silly, and there
should be a better way.

Any suggestions or code fragments?

Thanks!
Sam

I have a customer who wants to tailor his template verbiage
based upon
if the ticket is New, Updated, or Resolved … I was originally just
going by the $Ticket->Status in the template, but they have a funny
habit of creating the ticket with the “open” status. Obviously, this
throws off the template.

I have been trying to figure out if I can access the previous
value of
the $Ticket->Status, but so far have struck out. I’ve played with
trying to get the list of transactions for the ticket, but if it’s in
there, I can’t get the right magic to work.

I believe you want this in your Custom Condition section:

Process only if this is a new ticket.

return 1 if ($self->TransactionObj->Type eq ‘Create’);

And set Condition to “User Defined”. This will help you determine if
the ticket has just been created (whether it’s a status of “new” or
"open" or whatever). I believe you can also use this to check other
transactions, like ‘Resolve’.

I believe you want this in your Custom Condition section:

Process only if this is a new ticket.

return 1 if ($self->TransactionObj->Type eq ‘Create’);

Isn’t that just what the ‘On Create’ standard condition does?

Joshua Colson jcolson@voidgate.org

Right, and this brings us back to having 3 scrips and 3 templates again
:frowning:

That’s why I am trying to figure out how to do it in the template.

Thanks,
Sam

Joshua Colson wrote:> On Thu, 2006-04-27 at 08:57 -0700, Schultz, Eric wrote:

I believe you want this in your Custom Condition section:

Process only if this is a new ticket.

return 1 if ($self->TransactionObj->Type eq ‘Create’);

Isn’t that just what the ‘On Create’ standard condition does?

Whoops, neglected to see that you wanted to do something in the
template. Sorry.

Samuel P. Howard wrote:

Any suggestions or code fragments?

Template code:

{
if ( ($Ticket->Status eq ‘new’) || ($Ticket->Status eq ‘open’) ||
($Ticket->Status eq ‘stalled’) )
{
$OUT .=
"Thank you for submitting a request regarding

blah blah blah yada yada yada

";
}
elsif ($Ticket->Status eq ‘resolved’)
{
$OUT .=
"Thank you for contacting the Information Technology Help Desk.
For record-keeping purposes, we have assigned a ticket number
to your request

blah blah blah yada yada yada

";
}
}

You may review this request at

{$RT::WebURL}SelfService/Display.html?id={$Ticket->id}

                    Thank you,
                    Rice University, Information Technology
                    {$Ticket->QueueObj->CorrespondAddress()}

{$Transaction->Content()}

end code!

Rick R.

rickr.vcf (182 Bytes)