[rt-users] Change control

Tue Mar 14 14:30:02 EST 2006

   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==--
>