[rt-users] Approvals in 3.8.2

[Chia-liang Kao]

John,

John Alexson <jalexson <at> jajxn.net> writes:
> I was a bit confused by the revamped approvals in 3.8.2 as well --
> especially the lack of scrips for the ___Approvals queue.  It seems
> these actions are now hardcoded into the system -- at least for the
> default actions (I'm sure somebody can elaborate more and far better
> than me on this)

Yes, the logic for the approval workflow have been migrated to use the RT Rules
system, which avoids maintaining non-trivial code in database column as in
scrips.  If you are using the original approval scrips, everything should be
backward-compatible.

> Here's how I got mine to work:
> 
> - Enable the ___Approvals queue
> - In your templates for your approval queues, ensure that you have
> "Queue: ___Approvals" specified. 
> - Once the approval ticket got created in ___Approvals, everything
> started falling into place.
> 
> Most of the examples I had seen show using a custom queue here, but that
> didn't seem to be necessary with 3.8.2.
> 
> You probably understand this stuff already, but for benefit of other
> confused semi-newbs like myself:
> 
> I suppose my biggest stumbling block to figuring this out was my lack of
> understanding of same of the basic concepts of the Approvals system in
> general. The biggest one being that for every approval, there's actually
> TWO tickets:  The first being the normal ticket itself you want
> approved. This is the one that gets created or moved into your
> "Management Approvals" queue.  The second is a semi-hidden specialized
> ticket that gets put in the __Approvals queue (or possibly a queue you
> created prior to 3.8.2).  This is the ticket you see when clicking on
> the Approvals link and has the Approve, Deny, Notes, etc. fields.

Consider the Queue here being a specific workflow that requires approval, for
example a Purchase Order queue.  the ___Approvals queues and the tickets in it
(which records the states of the approvals) should in fact be hidden.  And you
might have different sets of approval rules for different queues, for example, a
PO queue and a Vacation Request queue.

> Like most things, this seems obvious once you know it, but piecing it
> together in the beginning can be a little tricky and frustrating.    

We are in the process of releasing a RT extension called WorkflowBuilder, which
should make the use of the approval system of fewer hassles.  Most notably you
can define multi-stage approvals without writing the template for the
CreateTickets action, and without modifying the scrips yourself.

Cheers,
CLK