Need help on an approval queue (coding customaction)

RT Users
1

Yes it did !

I had 2 users in the template, but for some strange reason, it was
creating 2 tickets, so 1 assigned to me (an approver) and the other one
was suppose to be to the manager yet the owner was set to nobody…

So I removed the manager from the template…

As see another problem, and possibly a bug:
When the approver selects “no Action” and enters a note, the information
in the not does not get to the requestor of the original ticket. I guess
this workflow is not working…

Apart from that, everything works fine.

Regards,

Nelson PereiraFrom: Kenneth Marshall [mailto:ktm@rice.edu]
Sent: Friday, April 11, 2008 8:37 AM
To: Nelson Pereira
Subject: Re: [rt-users] Need help on an approval queue (coding
customaction)

The creation of the ticket in the change control queue is
responsible for triggering all of the subticket creations.
There is a scrip called “On Create, issue Change Control Request
Approval”
that uses the template below. Other information about the scrip is:

Condition: On Create
Action: Create Tickets
Template: Create Change Control Approval
Stage: TransactionCreate
Custom condition: return (undef);
Custom action preparation code: return (undef);
Custom action cleanup code: return (undef);

The user in requesting approval creates the ticket in the
designated change control queue. This creates the approval
tickets. When they have all been approved, the requestor is
notified that their request was approved.

Hope this helps some.
Ken

Thanks Ken, but don’t you have a scrip that changes the ownership and
opens the ticket?

My biggest problem is that the manager needs to go to the original
ticket and take ownership and open it before it shows up in the
approval
queue…

Regards,

Nelson Pereira

-----Original Message-----
From: Kenneth Marshall [mailto:ktm@rice.edu]
Sent: Thursday, April 10, 2008 5:07 PM
To: Nelson Pereira
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Need help on an approval queue (coding
customaction)

Nelson,

Here is my “Create Change Control Approval” template:

===Create-Ticket: user1
Subject: New Pending Approval: {$Tickets{‘TOP’}->Subject}
Depended-On-By: TOP
Queue: IT: Approvals
Type: approval
Owner: user1
Content: Greetings,

There is a new change control item pending your approval:

"{$Tickets{'TOP'}->Subject}"

Please visit

{$RT::WebURL}Approvals/

to approve or reject this ticket, or to batch-process all
your pending approvals.
ENDOFCONTENT
===Create-Ticket: user2
Subject: New Pending Approval: {$Tickets{‘TOP’}->Subject}
Depended-On-By: TOP
Queue: IT: Approvals
Type: approval
Owner: user2
Content: Greetings,

There is a new change control item pending your approval:

"{$Tickets{'TOP'}->Subject}"

Please visit

{$RT::WebURL}Approvals/

to approve or reject this ticket, or to batch-process all
your pending approvals.
ENDOFCONTENT
…

This will create the approval tickets owned by the appropriate
users.

Ken

Anyone can shed a light on how to do this?

My setup right now when someone sends an email to nschange, the
ticket
gets created with owner nobody.

A second ticket gets created in the approval queue but with owner
RT_System.

I need this second ticket to be owned by a specific user, and the
status
changed to open.

This has to be a custom action but I don’t know what code to add
…?!?

It there a list of all RT objects and what they are?

Regards,

Nelson Pereira

From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of
Nelson
Pereira
Sent: Thursday, April 10, 2008 1:03 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Need help on an approval queue

Ok, I created an approval queue and need some special functions to
happen.

The workflow is like this:

  1.   A network Services Admin sends an email which RT put's into

the

approval queue.

  1.   I have setup the script to create an approval ticket.

  2.   Manager is to login and click on Approval link and approve

the

ticket.

The problem I’m seeing here is that the manager needs to click on
the
original ticket the admin created, then click on the Link’ed
approval
ticket created,

Then take ownership and open the ticket. Then he needs to go to the
approval Link on top to approve the approval ticket…?!?

This is way to many steps…

So how can I make a newly created ticket in the Approval Queue,
setup
ownership of that ticket to the requestor.

Then have RT create an approval ticket and setup the ownership to
the
manager and change the status to opened.

This way, the manager will get an email saying an approval ticket is
opened, he will login, click on Approval Link and approve the
ticket…

Thanks

Nelson Pereira
Senior Network Administrator

Protus IP Solutions Inc.
npereira@protus.com
phone: 613.733.0000 ext.528
MyFax: 613.822.5083
www.myfax.com

Refer your friends and colleagues to MyFax!
Click here for more information.
http://www.myfax.com/referral_program.asp

http://www.myfax.com

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

2

Here is my Permissions list setup in Excel for every queue/group/role
etc…
This way I can track everything…

Regards,

Nelson PereiraFrom: Kenneth Marshall [mailto:ktm@rice.edu]
Sent: Friday, April 11, 2008 10:54 AM
To: Nelson Pereira
Subject: Re: [rt-users] Need help on an approval queue (coding
customaction)

Permissions Setup.xls (34 KB)

3

Nelson,

Thanks for the spreadsheet. IT helps a great deal when it comes to

debugging. It looks like you grant your AdminCc role a lot of “global”
rights. If/when you have a lot of queues, this will prove troublesome ,
i.e. a AdminCc will have rights on queues you may not want that person
to mess with. We have 75 queues and we don’t let any AdminCc have some
of those rights (create, own, modify) globally because that would give
them the ability to interfere (even accidentally, like replying to an
email and accidentally putting in the wrong ticket id - ends up in a
queue he isn’t responsible for) on tickets where he isn’t wanted. So
most of theose rights we grant to that role on a queue-by-queue basis.
We already ran into those problems.
Also, you seem to have granted some rights to individual users. Not
really a good idea unless you never expect to have very many users (like
never more than 10). If some of those users are also in some of those
roles that have global rights, then you have compounded the difficulty
in debugging due to redundant privileges. YOu make take away the right
in one instance but it will remain because of the OTHER instance. So, I
would advise you to analyze the usage situation in your setup and
re-apply those rights accordingly. Remember, once a right is granted
globally to a role or system group, it hardly ever needs to granted
again at a lower level.
Now to what I think the problem is. Understanding rights is hard
enough, but with Approvals, the conditions under which they apply are
not consistent, at least that is my experiance as well as others I’ve
seen in the list. This is what we did,
We took away the ability to create tickets thru email from all queues
except one. That became our “Approvals” queue. We have an AdminCc and
user-defined group for that queue and they can own and modify the
tickets in that queue. If the problem is easily resolved by them, they
do it. If it requires work by someone else, THEY and only THEY move the
ticket to the appropriate queue along with their comments. The receiving
queue has IT’s own AdminCc and group that have rights to JUST that queue
and they work on the ticket until resolved, etc. We like this workflow
for several reasons:
1) The granting and exercise of privileges is more consistent.
2) All tickets get one ID number and that’s it. That way ALL comments,
modifications etc. stay with the ticket and it makes following the audit
trail much easier (as opposed to seeing one ticket number be approved
and another being worked on). The history stays with the ticket.
3) We force the review of all tickets instead of having them arrive,
helter-skelter into any queue (maybe even the wrong queue) so work
doesn’t get mismanaged. All tickets are prioritized compared to ALL
work, not just the work in one queue.
We haven’t had one problem with permissions or correspondence or
anything relating to approvals with this method. That’s all I can tell
you. Some Like the RT method and have gotten it to work. I guess that’s
why they make different flavors of ice cream (mine is TIn-roof sundae
;-). Hope this helps.

Kenn
LBNLOn 4/11/2008 7:55 AM, Nelson Pereira wrote:

Here is my Permissions list setup in Excel for every queue/group/role
etc…
This way I can track everything…

Regards,

Nelson Pereira

-----Original Message-----
From: Kenneth Marshall [mailto:ktm@rice.edu]
Sent: Friday, April 11, 2008 10:54 AM
To: Nelson Pereira
Subject: Re: [rt-users] Need help on an approval queue (coding
customaction)

On Fri, Apr 11, 2008 at 10:47:52AM -0400, Nelson Pereira wrote:

Also, what is an Actor as far as RT is concerned?

The person/user who make the update or change.

Ken

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

4

Thanks for that Ken,

Could you enlighten me as far as the permissions, what should not be
global and moved to the queue instead?

We wont have more then about 8-10 admins so…

Regards,

Nelson PereiraFrom: Kenneth Crocker [mailto:KFCrocker@lbl.gov]
Sent: Friday, April 11, 2008 1:15 PM
To: Nelson Pereira
Cc: Kenneth Marshall; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Need help on an approval queue (coding
customaction)

Nelson,

Thanks for the spreadsheet. IT helps a great deal when it comes

to
debugging. It looks like you grant your AdminCc role a lot of “global”
rights. If/when you have a lot of queues, this will prove troublesome ,
i.e. a AdminCc will have rights on queues you may not want that person
to mess with. We have 75 queues and we don’t let any AdminCc have some
of those rights (create, own, modify) globally because that would give
them the ability to interfere (even accidentally, like replying to an
email and accidentally putting in the wrong ticket id - ends up in a
queue he isn’t responsible for) on tickets where he isn’t wanted. So
most of theose rights we grant to that role on a queue-by-queue basis.
We already ran into those problems.
Also, you seem to have granted some rights to individual users.
Not
really a good idea unless you never expect to have very many users (like

never more than 10). If some of those users are also in some of those
roles that have global rights, then you have compounded the difficulty
in debugging due to redundant privileges. YOu make take away the right
in one instance but it will remain because of the OTHER instance. So, I
would advise you to analyze the usage situation in your setup and
re-apply those rights accordingly. Remember, once a right is granted
globally to a role or system group, it hardly ever needs to granted
again at a lower level.
Now to what I think the problem is. Understanding rights is hard

enough, but with Approvals, the conditions under which they apply are
not consistent, at least that is my experiance as well as others I’ve
seen in the list. This is what we did,
We took away the ability to create tickets thru email from all
queues
except one. That became our “Approvals” queue. We have an AdminCc and
user-defined group for that queue and they can own and modify the
tickets in that queue. If the problem is easily resolved by them, they
do it. If it requires work by someone else, THEY and only THEY move the
ticket to the appropriate queue along with their comments. The receiving

queue has IT’s own AdminCc and group that have rights to JUST that queue

and they work on the ticket until resolved, etc. We like this workflow
for several reasons:
1) The granting and exercise of privileges is more consistent.
2) All tickets get one ID number and that’s it. That way ALL
comments,
modifications etc. stay with the ticket and it makes following the audit

trail much easier (as opposed to seeing one ticket number be approved
and another being worked on). The history stays with the ticket.
3) We force the review of all tickets instead of having them
arrive,
helter-skelter into any queue (maybe even the wrong queue) so work
doesn’t get mismanaged. All tickets are prioritized compared to ALL
work, not just the work in one queue.
We haven’t had one problem with permissions or correspondence or

anything relating to approvals with this method. That’s all I can tell
you. Some Like the RT method and have gotten it to work. I guess that’s
why they make different flavors of ice cream (mine is TIn-roof sundae
;-). Hope this helps.

Kenn
LBNL