[rt-users] Using queues as state? (and per-queue menu customisation?)

[Howard Jones]

  On 26/07/2010 17:11, Kenneth Crocker wrote:
> Howard,
>
> We have a specific WorkFlow that involves some automatic processes 
> (automatically promoting Status and sending notifications) based on a 
> combination of values in the Status field (and some Custom Fields) and 
> we had to add a couple Status values (for staging QA testing) to 
> accomplish this. I also helped someone else do this via different 
> Queues with scrips that automatically sent the ticket to a new Queue 
> based on the values in Status and some Custom Fields. So, there are a 
> couple ways to do this. To decide exactly how, would depend on what 
> your workflow looks like, the types of restrictions and a few other 
> variables like who does what when and then what (plus any exceptions 
> to the rules). It really is important that you work out 
> (analyze/flowchart) the details of what you're looking for. It's 
> always easier to code decisions and procedures that are already worked 
> out.

Ah - flowcharts are something I have plenty of :-) This is an 
organisation that has taken the ITIL change and service-request 
processes and implemented them in Tivoli... Our own RT install is very 
much simpler, and these guys have decided they like the idea of simpler, 
just not *that* much simpler.

I'm not really interested in re-implementing all that, but one 
particular aspect is change approval. So users in group X can request a 
change, group Y must then approve that change, then group Z implement it.

So I think I want two queues: pending-changes, which group X can create 
tickets in, and approved-changes, which group Z can see and process 
tickets in. Then group Y has ModifyTicket in pending-changes, and 
CreateTicket in approved-changes. I think that will do what I want - 
plus some kind of user-interface to allow them to press an 'approve' or 
'deny' button, which makes appropriate ticket updates.

I don't see how it could do a vote, or quorum-style Change Board, but 
that's not so vital. In theory, the members of group X,Y and Z 
(especially the approvers and implementers) vary for different changes, 
but that can be more queues, worst-case.

Does this sound anything like what you did, Kenn?

Howard