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