[rt-users] ACLs to create tickets with custom fields

[Kenneth Crocker]

Jarred,


	Not exactly. Let me see if I can walk thru a sequence of events and 
maybe that will help. Trust me, it wasn't easy for me to understand at 
first either.

	1. Queue 'X' is created.
	2. Queue 'Y' is created.
	3. Group 'X-Support' is created.
	4. Group 'Y-Support' is created.
	5. Group 'Z-Admin' is created.
	6. Group 'X-Support' granted rights to see/modify all tickets in Queue 
'X' only.
	7. Group 'Y-Support' is also granted rights to see/modify all tickets 
in Queue 'X' and Queue 'Y'.
	8. Group 'Z-Admin' is granted 'SuperUser' rights to all tickets in 
Queue 'X' and Queue 'Y'. 'Z-Admin' is also granted "AdminCustomFields" 
rights globally.
	9. CF "Work-Category" created by Z-Admin. No other group can do that 
because no one else has the "AdminCustomFields" rights.
	10. Z-Admin adds values that can be selected for CF "Work-Category". No 
other group can do that because no one else has the "AdminCustomFields" 
rights.
	11. X-Support is granted "ModifyCustomField" right for CF "Work-=Category".
	12. Y-Support is granted "SeeCustomField" right for CF "Work-=Category".
	13. CF "Work-Category" is applied to Queue 'X'.
	14. Ticket created in Queue X. Value for CF "Work-Category" selected.
	15. Groups X-Support and Y-Support can SEE the ticket AND the value in 
CF "Work-Category".
	16 .Group X-Support can modify the regular ticket fields AND change 
that value in the CF "Work-Category".
	17. Group Y-Support can modify the regular ticket fields BUT CANNOT 
change the value in the CF "Work-Category" (of that ticket) because they 
do NOT have "ModifyCustomField" granted for that Custom Field.
	18. Ticket is created in Queue Y. No value for CF "Work-Category" 
selected (not applied to queue).
	19. Ticket is moved from Queue X to Queue Y.
	20. Group Y-Support can modify the regular ticket fields BUT CANNOT 
change the value in the CF "Work-Category" (of that ticket) because the 
CF has not yet been applied to Queue Y.
	21. Same ticket is moved back to Queue X.
	22. Same situation as numbers 15, 16, & 17. The CF "work-Category" does 
NOT need to be re-applied or re-created for the ticket. It was always 
there in the DataBase even when the ticket was moved.
	Custom Fields are treated as a separate entity/object in RT. Permission 
to a queue/ticket do NOT mean you have permission to the CF.

	Permissions for a ticket are granted thru ACLs that are granted to 
groups and roles to a queue. Permission to "ModifyTicket" does NOT give 
you the ability to "ModifyCustomField". That right is granted thru 
separate ACLs to the CF to a group(s). I didn't mention granting rights 
to users individually because that is just a real bad maintenance 
nightmare and shouldn't be considered unless you only have a few users 
in the system.

	Does any of this makes sense? I hope it helps.


Kenn
LBNL
	

On 8/21/2008 10:31 AM, Jerrad Pierce wrote:
> 
> 
> On Thu, Aug 21, 2008 at 13:24, Kenneth Crocker <KFCrocker at lbl.gov 
> <mailto:KFCrocker at lbl.gov>> wrote:
> 
>     Jerrad,
> 
> 
>            Actually, the "ModifyCustomField" privilege doesn't have
>     anything to do with creating tickets. When a ticket is created, an
>     OBJECTCUSTOMFIELDVALUES table record (where the value of the CF for
>     that ticket is held) is created automatically for that ticket for
>     each custom field applied to the queue the ticket resides in,
>     provided that there is a value for that custom field for that
>     ticket. The "ModifyCustomField" privilege allows a user to put a
>     value into that CF for that ticket. If a ticket is created and no
>     value is given for a particular CF, then the OBJECTCUSTOMFIELDVALUES
>     record is NOT created. If, at a later date/time, a user with that
>     privilege goes into the ticket and enters a value for that CF, then
>     the OBJECTCUSTOMFIELDVALUES record is created. The
>     OBJECTCUSTOMFIELDVALUES table record has a key (OBJECTID) to each
>     ticket it is holding values for. I hope this helps.
> 
> So if I'm reading this right (and I may not be), you're saying that one 
> should be able to set
> the custom field values for a new ticket without ModifyCustomField. That 
> is what I would
> expect, but it does not seem to be the case. It's not possible to set 
> custom field values on
> ticket creation (via REST, in 3.8) without that right. Both the CLI and 
> RT::Client:REST fail to
> set the fields without this right.
> 
> -- 
> Cambridge Energy Alliance: Save money & the planet