I’ve managed to get stuck with looking at emulating an existing Tivoli
TSRM process with RT. It’s a somewhat complex workflow for change
management, where a request goes through a series of states, and in each
state there are different restrictions on what can happen, and who can
do it.
I’m thinking that an RT queue for each state is probably the way to do
this, with appropriate group permissions on each queue. Then some kind
of menu customisation for the actions, that push tickets into other queues.
Is there an existing way (other than a giant case statement type of
thing in /Callbacks/Ticket/Elements/Tabs) to do per-queue customisation
like this?
Has anyone else done this kind of thing? I’m torn between trying to
follow the existing stuff slavishly, and getting the actual process
simplified instead 
Thanks for any illumination…
Howie
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.
Hope this helps.
Kenn
LBNLOn Mon, Jul 26, 2010 at 2:30 AM, Howard Jones howie@thingy.com wrote:
I’ve managed to get stuck with looking at emulating an existing Tivoli
TSRM process with RT. It’s a somewhat complex workflow for change
management, where a request goes through a series of states, and in each
state there are different restrictions on what can happen, and who can
do it.
I’m thinking that an RT queue for each state is probably the way to do
this, with appropriate group permissions on each queue. Then some kind
of menu customisation for the actions, that push tickets into other queues.
Is there an existing way (other than a giant case statement type of
thing in /Callbacks/Ticket/Elements/Tabs) to do per-queue customisation
like this?
Has anyone else done this kind of thing? I’m torn between trying to
follow the existing stuff slavishly, and getting the actual process
simplified instead 
Thanks for any illumination…
Howie
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
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
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
LBNLOn Mon, Jul 26, 2010 at 2:10 PM, Howard Jones howie@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
Kenneth Crocker wrote:
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.
I started there, but as far as I could tell, the built-in Approvals
process is set up to approve the resolving of a ticket - the description
is that the master ticket can’t be resolved until the dependent approval
ticket is resolved (approved). I want that the master ticket isn’t
visible to the implementer until it’s been approved.
(actually, there isn’t a page on the wiki describing Approvals at all. I
think I must have gotten that from the book.)
I’ll take another look in the morning, before starting on multiple queues…
Cheers,
Howard