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

[Kenneth Crocker]

Howard,

Not exactly. We have a Review & Approval process, which is what you seem to
want and a QA approval process which is a whole different process. It looks
like you want the ticket "approved" before get worked on and RT already has
that ability with it's own "Approvals". When you use that workflow, RT
basically creates an "Approval" Queue named for each Queue that uses that
process automatically. Queue-1 would have an "Approval" Queue named for and
Queue-2 would also have an "Approval" Queue named for it.

RT 3.8 even has an additional Tab called "Approvals" you can use. You should
probably check that out.

Kenn
LBNL

On Mon, Jul 26, 2010 at 2:10 PM, Howard Jones <howie at thingy.com> wrote:

>  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
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100726/e1aeaa8e/attachment.htm>