Approvals in 3.8.2

I had the approval system working in 3.8.1, but for some reason it no
longer works in 3.8.2 as expected.

If a new ticket is created in our approval queue "Management Approvals"
it sends out a normal ticket email, not the approval email.

In the “Management Approvals” queue there is a scrip:

When an approval ticket is created, notify the Owner and AdminCc of the
item awaiting their approval
$self->TicketObj->Type eq ‘approval’ and

          $self->TransactionObj->Field eq 'Status'         and

          $self->TransactionObj->NewValue eq 'open'   and

          eval { $T::Approving = ($self->TicketObj->AllDependedOnBy(

Type => ‘ticket’ ))[0] }

I had a look at the ___Approvals queue to see if it had changed, to find
no Scrips at all. There were some updated templates, which I copied over
to “Management Approvals”.

I know a small change was listed in the change log for 3.8.2; has this
impacted my system?

Anyone have a clue why the approvals don’t work as expected? I don’t
think they are being marked as an Approval either, as they just show up
as a normal ticket and not in the Approvals page.

I had the approval system working in 3.8.1, but for some reason it no
longer works in 3.8.2 as expected.

If a new ticket is created in our approval queue “Management
Approvals” it sends out a normal ticket email, not the approval email.

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)

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.

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

Good luck!

John Alexson

Thanks for the info.

The way I had hoped to use it was having a “Approval” button on the ticket screen, and when pressed it would send all the info to the create new ticket/depends on screen with “Management Approvals” This bit works. I thought I would need separate approval queues for different groups of people.

So if I add Queue: ___Approvals to every template in the Management approvals queue, it should work correctly? They are just copies of the ones from the ___Approvals queue.

So should I remove the scrips from the Management Approvals queue?

Thanks,
AlexFrom: John Alexson [mailto:jalexson@jajxn.net]
Sent: 13 February 2009 12:02
To: Alex Young
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Approvals in 3.8.2

I had the approval system working in 3.8.1, but for some reason it no
longer works in 3.8.2 as expected.

If a new ticket is created in our approval queue “Management
Approvals” it sends out a normal ticket email, not the approval email.

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)

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.

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

Good luck!

John Alexson

In the “Management Approvals” queue there is a scrip:

When an approval ticket is created, notify the Owner and AdminCc of
the item awaiting their approval
$self->TicketObj->Type eq ‘approval’ and

          $self->TransactionObj->Field eq 'Status'         and

          $self->TransactionObj->NewValue eq 'open'   and

          eval { $T::Approving =

($self->TicketObj->AllDependedOnBy( Type => ‘ticket’ ))[0] }

I had a look at the ___Approvals queue to see if it had changed, to
find no Scrips at all. There were some updated templates, which I
copied over to “Management Approvals”.

I know a small change was listed in the change log for 3.8.2; has this
impacted my system?

Anyone have a clue why the approvals don’t work as expected? I don’t
think they are being marked as an Approval either, as they just show
up as a normal ticket and not in the Approvals page.


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Thanks for the info.

The way I had hoped to use it was having a “Approval” button on the ticket screen, and when pressed it would send all the info to the create new ticket/depends on screen with “Management Approvals” This bit works. I thought I would need separate approval queues for different groups of people.

My knowledge of the approvals system is admittedly limited, but it
sounds feasible. Hopefully somebody more knowledgable can comment . . .

So if I add Queue: ___Approvals to every template in the Management approvals queue, it should work correctly? They are just copies of the ones from the ___Approvals queue.

So should I remove the scrips from the Management Approvals queue?

To clarify how my system is setup and works (under 3.8.2):

  • I have a queue for every individual who can approve a ticket.
  • Each one of those queues has exactly one template named “Create
    Approval”. This template looks almost identical to the examples seen in
    the wiki and the RT Essentials book, except the Queue: is always
    _Approvals
  • Each queue has exactly two scrips: one that responds to the “On
    Create” and the other that responds to the “On Queue Change” events.
    (both using the Create Approval template)
  • I have no other scrips or templates in the queues
  • Other than some cosmetic changes, the templates and scrips in the
    ___Approvals are pretty much left untouched.
  • When a ticket needs to be approved, it can either be created directly
    in the approving users’ queue, or an existing ticket can be moved there
    from the Basics screen.

I’m sure some more complex mods can be setup, such as the one you’re
making, but this seems to work pretty well for generic approvals.

Again, hopefully somebody more knowledgable than me can comment on this.

Good luck!

John Alexson

John,

John Alexson <jalexson 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

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.

Thanks Chia-liang!

The WorkflowBuilder sounds like just the thing I’ve been needing to work
on some flows I’ve been tasked with automating. I had even considered
building a crude tool for my own use.

John Alexson

Hello,

This extension looks very interesting. Do you have an idea of the
release date ? Even a devel version for testing ?

Thanks!
L.B.

We are in the process of releasing a RT extension called WorkflowBuilder

Any sign of this anywhere any of the great unwashed can get it, it doesn’t
seem to be on the CPAN…?

Richard Foley
Ciao - shorter than aufwiedersehen

Hello,

This extension looks very interesting. Do you have an idea of the
release date ? Even a devel version for testing ?

I saw that it was released now:

Drew
Drew Taylor * Web development & consulting
Email: drew@drewtaylor.com * Site implementation & hosting
Web : www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres