[rt-users] Change control

Tue Mar 28 14:01:37 EST 2006

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:

>   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
>  
>
>>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:
>>
>>    
>>
>>>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
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>>
>>>Community help: http://wiki.bestpractical.com
>>>Commercial support: sales at bestpractical.com
>>>
>>>
>>>Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>>>Buy a copy at http://rtbook.bestpractical.com
>>>
>>>
>>>We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/abo
>>>      
>>>
>>ut/jobs.html
>>    
>>
>>--------------000805060204060805090304
>>Content-Type: text/html; charset=us-ascii
>>Content-Transfer-Encoding: 7bit
>>
>><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
>><html>
>><head>
>> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
>> <title></title>
>></head>
>><body bgcolor="#ffffff" text="#000000">
>>Chuck,<br>
>><br>
>>    We are attempting to do just that here at LBNL. The "APPROV
>>AL"
>>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 on
>>e
>>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.<br>
>><br>
>>Kenn<br>
>><br>
>>Chuck Boeheim wrote:<br>
>><blockquote cite="mid4416F775.8020307 at slac.stanford.edu" type="cite">Hi
>>Folks,
>> <br>
>>Has anyone come up with any good methodologies for change control
>> <br>
>>of an RT installation?  Many of the components are database records
>> <br>
>>that don't seem amenable to CVS control, scrips and templates as well
>> <br>
>>as custom field definitions and queue setups.  We'd like to have a
>>record
>> <br>
>>of what changed when and by whom, and be able to reconstruct the
>> <br>
>>state of the system or back out a change.  Even an audit record of 
>>what
>> <br>
>>changed would be better than nothing, even if it can't be used directly
>> <br>
>>for backing out a change.  Has anyone tackled this?
>> <br>
>>Best,
>> <br>
>>-Chuck Boeheim
>> <br>
>>Stanford Linear Accelerator Center
>> <br>
>> <pre wrap="">
>><hr size="4" width="90%">
>>_______________________________________________
>><a class="moz-txt-link-freetext" href="http://lists.bestpractical.com/cgi-bin/
>>mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/list
>>info/rt-users</a>
>>
>>Community help: <a class="moz-txt-link-freetext" href="http://wiki.bestpractic
>>al.com">http://wiki.bestpractical.com</a>
>>Commercial support: <a class="moz-txt-link-abbreviated" href="mailto:sales at bes
>>tpractical.com">sales at bestpractical.com</a>
>>
>>
>>Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>>Buy a copy at <a class="moz-txt-link-freetext" href="http://rtbook.bestpractic
>>al.com">http://rtbook.bestpractical.com</a>
>>
>>
>>We're hiring! Come hack Perl for Best Practical: <a class="moz-txt-link-freete
>>xt" href="http://bestpractical.com/about/jobs.html">http://bestpractical.com/a
>>bout/jobs.html</a></pre>
>></blockquote>
>></body>
>></html>
>>
>>--------------000805060204060805090304--
>>
>>--===============1567546002==
>>Content-Type: text/plain; charset="us-ascii"
>>MIME-Version: 1.0
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: inline
>>
>>_______________________________________________
>>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>>
>>Community help: http://wiki.bestpractical.com
>>Commercial support: sales at bestpractical.com
>>
>>
>>Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>>Buy a copy at http://rtbook.bestpractical.com
>>
>>
>>We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/abou
>>t/jobs.html
>>--===============1567546002==--
>>
>>    
>>
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Community help: http://wiki.bestpractical.com
>Commercial support: sales at bestpractical.com
>
>
>Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
>Buy a copy at http://rtbook.bestpractical.com
>
>
>We're hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060328/eca87133/attachment.htm>