Precedence for group rights for custom fields vs. queue

RT Users
1

Hi List,

I’ve run up against something in RT that does not work intuitively for me. I
apologize up front for the length of this e-mail, but I wanted to provide
all pertinent background so others can understand the problem I face.

Background:

I’ve created a workflow in RT that utilizes a couple of different queues. Our
Customer Service department enters a ticket in one queue (“Sales Order”) and
when ready to send the item on for approvals, transfers the ticket to an
approval queue (“Sales Order Approval”) which then triggers scrips to e-mail
a string of approvers in a particular order. The way this works is each
group of approvers have certain custom fields that they edit and when an
authorized approver user fills in all their required fields, a scrip
executes when then e-mails the next approver in line with a ticket link so
they can fill in their custom fields. At the end of a long string of
reviewers filling in their fields, the scrip e-mails notification to the
ticket owner that the approval is completed and transfers the ticket back to
the “Sales Order” queue, modifying the ticket subject to indicate it’s
completed.

Group rights have been set up on the “Sales Order” queue so tickets can only
be created and modified by Customer Service. For the approval queue, all
groups of approvers have the right to modify tickets. The individual custom
fields that hold the approval information are controlled, however, by group
rights tied to the approving individuals for each step in the approval
process, thereby disallowing approvers from different teams the ability to
overwrite each other’s custom fields for approval.

This system, while it sounds complicated, actually works simply and
automatically and has effectively replaced a manual sign off process that
previously existed.

The Problem:

At one point a requirement was submitted to allow approvers the ability to
see previously signed off tickets. This was implemented using group rights
on the “Sales Order” queue that provided ticket viewing rights, but no
"write" rights for approvers. The thought was that as long as the ticket
sat in a queue where the user can see the tickets but cannot modify them,
then there should be no chance for a reviewer to modify their previous
approval. What I have found though is that it appears the group right which
allows access to modify a custom field seems to override the group right on
the queue that disallows modification to the ticket. This means an
approver who was simply allowed to view tickets in the queue can still
change their custom field data after it’s gone through the complete review
cycle, something we do not want.

Are custom field group rights supposed to override queue group rights?

If this is the current design, is this a bug or oversight or is it
intentional?

If anyone else has encountered this, are there any hacks to fix it?

Many thanks in advance.

Jon

2

Hi List,

I’ve run up against something in RT that does not work intuitively for me. I
apologize up front for the length of this e-mail, but I wanted to provide
all pertinent background so others can understand the problem I face.

Background:

I’ve created a workflow in RT that utilizes a couple of different queues. Our
Customer Service department enters a ticket in one queue (“Sales Order”) and
when ready to send the item on for approvals, transfers the ticket to an
approval queue (“Sales Order Approval”) which then triggers scrips to e-mail
a string of approvers in a particular order. The way this works is each
group of approvers have certain custom fields that they edit and when an
authorized approver user fills in all their required fields, a scrip
executes which then e-mails the next approver in line with a ticket link so
they can fill in their custom fields. At the end of a long string of
reviewers filling in their fields, the scrip e-mails notification to the
ticket owner that the approval is completed and transfers the ticket back to
the “Sales Order” queue, modifying the ticket subject to indicate it’s
completed.

Group rights have been set up on the “Sales Order” queue so tickets can only
be created and modified by Customer Service. For the approval queue, all
groups of approvers have the right to modify tickets. The individual custom
fields that hold the approval information are controlled, however, by group
rights tied to the approving individuals for each step in the approval
process, thereby disallowing approvers from different teams the ability to
overwrite each other’s custom fields for approval.

This system, while it sounds complicated, actually works simply and
automatically and has effectively replaced a manual sign off process that
previously existed.

The Problem:

At one point a requirement was submitted to allow approvers the ability to
see previously signed off tickets. This was implemented using group rights
on the “Sales Order” queue that provided ticket viewing rights, but no
"write" rights for approvers. The thought was that as long as the ticket
sat in a queue where the user can see the tickets but cannot modify them,
then there should be no chance for a reviewer to modify their previous
approval. What I have found though is that it appears the group right which
allows access to modify a custom field seems to override the group right on
the queue that disallows modification to the ticket. This means an
approver who was simply allowed to view tickets in the queue can still
change their custom field data after it’s gone through the complete review
cycle, something we do not want.

Are custom field group rights supposed to override queue group rights?

If this is the current design, is this a bug or oversight or is it
intentional?

If anyone else has encountered this, are there any hacks to fix it?

Many thanks in advance.

Jon

3

Hi List,

I’ve run up against something in RT that does not work intuitively for me. I
apologize up front for the length of this e-mail, but I wanted to provide
all pertinent background so others can understand the problem I face.

Background:

I’ve created a workflow in RT that utilizes a couple of different queues. Our
Customer Service department enters a ticket in one queue (“Sales Order”) and
when ready to send the item on for approvals, transfers the ticket to an
approval queue (“Sales Order Approval”) which then triggers scrips to e-mail
a string of approvers in a particular order. The way this works is each
group of approvers have certain custom fields that they edit and when an
authorized approver user fills in all their required fields, a scrip
executes when then e-mails the next approver in line with a ticket link so
they can fill in their custom fields. At the end of a long string of
reviewers filling in their fields, the scrip e-mails notification to the
ticket owner that the approval is completed and transfers the ticket back to
the “Sales Order” queue, modifying the ticket subject to indicate it’s
completed.

Group rights have been set up on the “Sales Order” queue so tickets can only
be created and modified by Customer Service. For the approval queue, all
groups of approvers have the right to modify tickets. The individual custom
fields that hold the approval information are controlled, however, by group
rights tied to the approving individuals for each step in the approval
process, thereby disallowing approvers from different teams the ability to
overwrite each other’s custom fields for approval.

This system, while it sounds complicated, actually works simply and
automatically and has effectively replaced a manual sign off process that
previously existed.

The Problem:

At one point a requirement was submitted to allow approvers the ability to
see previously signed off tickets. This was implemented using group rights
on the “Sales Order” queue that provided ticket viewing rights, but no
“write” rights for approvers. The thought was that as long as the ticket
sat in a queue where the user can see the tickets but cannot modify them,
then there should be no chance for a reviewer to modify their previous
approval. What I have found though is that it appears the group right which
allows access to modify a custom field seems to override the group right on
the queue that disallows modification to the ticket. This means an
approver who was simply allowed to view tickets in the queue can still
change their custom field data after it’s gone through the complete review
cycle, something we do not want.

Are custom field group rights supposed to override queue group rights?

If this is the current design, is this a bug or oversight or is it
intentional?

If anyone else has encountered this, are there any hacks to fix it?

Many thanks in advance.

Jon Codispoti
IT Manager*
Orthodyne Electronics, Inc.****
Office: 949-399-2929, Ext. 1006**
Fax: 949-660-8514******
jon.codispoti@orthodyne.com*

4

Jon,

You're situation is similar to ours with a few differences. We only

move the ticket to a “support” queue once, after it is initally approved
for work. Once there, it is modified by the support personnel until it
is ready for our “QA” workFlow. We have several Custom Fields in play
for that process and, of course, allow only members of a certain group
to modify those fields. Those "Approvers CANNOT modify any other field
in the ticket, with the exception of comments, but those are two
different permissions.
You pose a fairly tricky problem, but question1 doesn’t quite seem to
specifically address it.
Question 1: Do CF rights override Queue/Group rights? They don’t
interrelate at all, other than when a CF IS applied to a Queue, the CF
rights of a group come into play. The CF group rights are for a CF,
regardless of queue. RT sees this as two separate issues. I have an
instance where a CF is applied to a queue but no one can see it or
modify it. I use it internally for certain scrip conditions and I set it
internally based on other conditions (this, by the way, might be an idea
to consider for your problem). Having rights to a CF in no way impinges
on the rights you granted for a queue.
Question 2 & 3: I would consider the following:
1) Create a CF that NO ONE can modify. Apply it to the appropriate queues.
2) Write a scrip that will modify that new CF with a more explicit
description of the value expressed by the CF that was changed by the
approvers. Condition that action on a change to the ORIGINAL CF that the
approvers CAN modify.
3) Grant “SeeCustomField” (ONLY!!!) for the appropriate groups to that
new CF.
4) Do not apply the old CF to the queues where the approvers are only
supposed to be “looking” at them.

This should allow you approvers to modify the CF in the "Approval"

queue where they have access AND at the same time, you are updating the
CF that anyone can SEE (by not change) in the non-approval queue.
I hope I’m describing this in an understandable way. The terms we use
in RT CAN be a little misleading, sometimes. Hope this helps.

Kenn
LBNLOn 11/19/2008 2:02 PM, Jon Codispoti wrote:

Hi List,

I’ve run up against something in RT that does not work intuitively for
me. I apologize up front for the length of this e-mail, but I wanted to
provide all pertinent background so others can understand the problem I
face.

Background:

I’ve created a workflow in RT that utilizes a couple of different
queues. Our Customer Service department enters a ticket in one queue
(“Sales Order”) and when ready to send the item on for approvals,
transfers the ticket to an approval queue (“Sales Order Approval”) which
then triggers scrips to e-mail a string of approvers in a particular
order. The way this works is each group of approvers have certain
custom fields that they edit and when an authorized approver user fills
in all their required fields, a scrip executes when then e-mails the
next approver in line with a ticket link so they can fill in their
custom fields. At the end of a long string of reviewers filling in
their fields, the scrip e-mails notification to the ticket owner that
the approval is completed and transfers the ticket back to the “Sales
Order” queue, modifying the ticket subject to indicate it’s completed.

Group rights have been set up on the “Sales Order” queue so tickets can
only be created and modified by Customer Service. For the approval
queue, all groups of approvers have the right to modify tickets. The
individual custom fields that hold the approval information are
controlled, however, by group rights tied to the approving individuals
for each step in the approval process, thereby disallowing approvers
from different teams the ability to overwrite each other’s custom fields
for approval.

This system, while it sounds complicated, actually works simply and
automatically and has effectively replaced a manual sign off process
that previously existed.

The Problem:

At one point a requirement was submitted to allow approvers the ability
to see previously signed off tickets. This was implemented using group
rights on the “Sales Order” queue that provided ticket viewing rights,
but no “write” rights for approvers. The thought was that as long as
the ticket sat in a queue where the user can see the tickets but cannot
modify them, then there should be no chance for a reviewer to modify
their previous approval. What I have found though is that it appears
the group right which allows access to modify a custom field seems to
override the group right on the queue that disallows modification to the
ticket. This means an approver who was simply allowed to view tickets
in the queue can still change their custom field data after it’s gone
through the complete review cycle, something we do not want.

Are custom field group rights supposed to override queue group rights?

If this is the current design, is this a bug or oversight or is it
intentional?

If anyone else has encountered this, are there any hacks to fix it?

Many thanks in advance.

–
Jon Codispoti
/IT Manager//
/Orthodyne Electronics, Inc.///
Office: 949-399-2929, Ext. 1006//
Fax: 949-660-8514///**/
jon.codispoti@orthodyne.com mailto:jon.codispoti@orthodyne.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