Is it normal that this should require the ModifyCustomField right? Because
it doesn’t seem at all intuitive to me,
nor does the documentation clearly indicate that this should be the case.
Alas, I’ve lost quite a bit of time due
to this :-/
Cambridge Energy Alliance: Save money & the planet
Jerrad,
Actually, the "ModifyCustomField" privilege doesn't have anything todo 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
This all make sense but it still doesn’t seem to actually answer my
question, which is all about your step 14. Because setting custom fields can
happen at ticket creation, it’s not
obvious to me that one should need a right called modify, but this
appears to be the case,
and what I was trying to verify. Perhaps if there were clearer documentation
of what the rights
actually mean (not even present in ‘Essentials’) such a difference in
interpretation might not
occur. Regardless, I have added a note to the wiki to try and help clarify
this for anyone else
stung by this in the future:
http://wiki.bestpractical.com/view/ModifyCustomField
The prior wiki description " This right allows the user to associate
existing custom field
values with the custom field’s objects, e.g. tickets, users, etc."
presupposes knowledge
of RT’s schema. this read to me like “users with this right get to add
previously defined
CFs to objects” (Configuration>Global>Custom Fields>*); clearly not
something you want
to grant to lowlier users, and so I had not. Whereas I imagine it’s supposed
to mean “you
get to set CF values for objects (which is done internally with some
inter-table references.)”
To further clarify, given the name ModifyCustomField, my interpretation of
the right
prior to discovering the wiki entry was that it meant only users with this
right could alter
the field after it had been initially set on ticket creation.
Cambridge Energy Alliance: Save money & the planet
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.
Kenn
LBNLOn 8/21/2008 9:42 AM, Jerrad Pierce wrote:
Is it normal that this should require the ModifyCustomField right?
Because it doesn’t seem at all intuitive to me,
nor does the documentation clearly indicate that this should be the
case. Alas, I’ve lost quite a bit of time due
to this :-/–
Cambridge Energy Alliance: Save money & the planet
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.comDiscover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
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
LBNLOn 8/21/2008 10:31 AM, Jerrad Pierce wrote:
On Thu, Aug 21, 2008 at 13:24, Kenneth Crocker <KFCrocker@lbl.gov mailto:KFCrocker@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
Jerrad,
I am attaching a document we use for teaching our Queue Admins what the
privileges mean for our installation.
Kenn
LBNLOn 8/21/2008 2:28 PM, Jerrad Pierce wrote:
This all make sense but it still doesn’t seem to actually answer my
question, which is all about your step 14. Because setting custom fields
can happen at ticket creation, it’s not
obvious to me that one should need a right called modify, but this
appears to be the case,
and what I was trying to verify. Perhaps if there were clearer
documentation of what the rights
actually mean (not even present in ‘Essentials’) such a difference in
interpretation might not
occur. Regardless, I have added a note to the wiki to try and help
clarify this for anyone else
stung by this in the future:
ModifyCustomField - Request Tracker WikiThe prior wiki description " This right allows the user to associate
existing custom field
values with the custom field’s objects, e.g. tickets, users, etc."
presupposes knowledge
of RT’s schema. this read to me like “users with this right get to add
previously defined
CFs to objects” (Configuration>Global>Custom Fields>*); clearly not
something you want
to grant to lowlier users, and so I had not. Whereas I imagine it’s
supposed to mean “you
get to set CF values for objects (which is done internally with some
inter-table references.)”To further clarify, given the name ModifyCustomField, my interpretation
of the right
prior to discovering the wiki entry was that it meant only users with
this right could alter
the field after it had been initially set on ticket creation.–
Cambridge Energy Alliance: Save money & the planet
RT Rights.doc (56 KB)