Approval problems with RT3

RT Users
1

Good day. The company I work for has been quite happy with RT3 as a
replacement for an antiquated system we were using, and for general use
all is going quite well. However, the management wants to enable the
approval system, and this is an area where I have run into some trouble
in configuration and implementation.

Basically, I can create a queue (Approbations) and then create a global
template of the following form, named ``DevApprovals’’:

===Create-Ticket: codereview
Depended-On-By: {$Tickets{'TOP'}->Id}
Queue: Approbations
Type: Approval
Content: Someone has created a ticket. you should review and approve 
it, so they can finish their work. 
ENDOFCONTENT

Then I add an ``Approval Scrip’’ to the Support queue:

On Create Create Tickets with template DevApprovals

This works in that when a ticket is created in the Support queue, a
ticket of type Approval is also created. However, from here some
problems occur, which I find quite puzzling:

The ``Depended-On-By'' condition is not set, regardless of the
fact that it exists in the template.

The Approval ticket does not show up in the Approbations queue,
and is only accessible via the ``Approval'' link to the left of
the main display.

Viewing the ticket in the ``Approval'' section shows the
approval ticket, but not the information for the ticket that it
is referencing. So, if you have a ticket named ``testing
still'', you will have an approval ticket created with the name
``Code review for testing still'' but nothing further.

I have experimented with these approval tickets, particularly in the
range of setting dependencies. I found that by manually making a ticket
dependent on one of these approval tickets, the content of the ticket
requireing approval shows up in the ``My approvals’’ interface, which
is good. However, this doesn’t fix the problem that this isn’t being
done automatically by the scrip. Also, I found that although I could not
resolve the ticket with a dependency while the approval was pending,
after denying the approval ticket I was able to resolve the ticket which
depended on the approval, even though that approval was denied. This is
a bit confusing, as I would have thought that a rejected approval ticket
would have also rejected the ticket that depended on that approval.

I’m sure someone has implemented this successfully, but I did not find
much in the PDF documentation on RT3 about setting up approvals. I had
to get the information I do have from browsing the mailing list
archives, so I don’t know that I set this up correctly. Please, could
someone point me to a reference on setting this up, or perhaps provide
me with the valuable clue I need to get this going myself? Thank you.

My setup is as follows - I am using RT 3.0.2 on Debian Linux with a
mysql backend and Apache as the web server.

Joe Gosselin
Jr. System Administrator

2

The same problems exist in RT 3.0.3pre1.

Especially the missing Depended-On-By relationship stops making the
approvals work the way I though it would. Did you get any help on this one?

I also had problems specifying which user to own the approval ticket, that
is, the user who acts as approver. It seems to default to the user creating
the original ticket, even though I specify the owner in the approval
template.

Henrik von Gunten
Hugin ASA

3 
===Create-Ticket: codereview
Subject: Code review for {$Tickets{'TOP'}->Subject}
Depended-On-By: {$Tickets{'TOP'}->Id}

Per my experience, you want:

Depended-On-By: TOP

That is, the relationship is between Create-Ticket labels, not
actual ticket IDs. That means this should work too:

Depended-On-By: codereview

In a few weeks I shall release my Workflow extensions on top of
RT, which lets you edit Workflow branches, conditions and trees
using the WebUI instead of the text interface.

Thanks,
/Autrijus/

4 
===Create-Ticket: codereview
Subject: Code review for {$Tickets{'TOP'}->Subject}
Depended-On-By: {$Tickets{'TOP'}->Id}

Per my experience, you want:

Depended-On-By: TOP

That is, the relationship is between Create-Ticket labels, not
actual ticket IDs. That means this should work too:

Depended-On-By: codereview

In a few weeks I shall release my Workflow extensions on top of
RT, which lets you edit Workflow branches, conditions and trees
using the WebUI instead of the text interface.

Thanks,
/Autrijus/

Thank you so much, this solved my problem entirely. As an aside, the
documentation for RT3 is rather misleading in this (and a few other
places)… I may send a mailing to this list about some of the omissions
and incorrect aspects of the docs in the near future (I know you aren’t
the doc maintainer, I’m just thinking out loud).

I’ll definitely take a look at your Workflow extensions when you are
finished, they sound like just what I’m looking for. As an aside, will
your extensions allow for Approvals to be tied to specific queues and
the like? We are small enough here that it isn’t a big deal that the
manager of the Creative group can see (and approve) tickets from
Development, but in the future it might be nice to have Approvals be
tied to a queue rather than be a sitewide managerial approval dumping
area.

Joe Gosselin

5

Thank you so much, this solved my problem entirely. As an aside, the
documentation for RT3 is rather misleading in this (and a few other
places)… I may send a mailing to this list about some of the omissions
and incorrect aspects of the docs in the near future (I know you aren’t
the doc maintainer, I’m just thinking out loud).

That will be very welcome. It is currently one of the (if not the) least
documented area in RT, and I hadn’t gathered tuits to translate our
Chinese tutorial back to English. :-/

I’ll definitely take a look at your Workflow extensions when you are
finished, they sound like just what I’m looking for. As an aside, will
your extensions allow for Approvals to be tied to specific queues and
the like?

Yes. Global Workflow is very rare indeed – each queue should have its
own “Default Approval” template and have a Scrip that calls it, instead
of doing anything global.

Actually the code has been sitting in the snapshot tarball of elixus.org
branch forever ( http://p4.elixus.org/snap/rt.tar.gz ) – installing it
using the regular RT upgrade procedure will probably work out-of-box,
but I hadn’t tested that extensively so there’s no guarantees.

A full backup of database is advised before trying it. Don’t forget
to restart apache.

After upgrade, use the two links below for the alternative UI:
http://rt.example.com/Edit/ # for admin
http://rt.example.com/Work/ # for user
The classic UI is intact and may still be used.

Select a Queue from /Edit/, and click “Workflow”, to use the Workflow
editor. It should be more-or-less intuitive to use; you may also use
the “Export” button to export out a “===Create-Ticket”-style template,
tweak it by hand, and Import it back again.

Let me know if that does not work for you.

Thanks,
/Autrijus/