[rt-users] Precedence for group rights for custom fields vs. queue

[Kenneth Crocker]

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
LBNL

On 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 at orthodyne.com <mailto:jon.codispoti at orthodyne.com>/
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com