<div dir="ltr">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<br>obvious to me that one should need a right called *modify*, but this appears to be the case,<br>
and what I was trying to verify. Perhaps if there were clearer documentation of what the rights<br>actually mean (not even present in 'Essentials') such a difference in interpretation might not<br>occur. Regardless, I have added a note to the wiki to try and help clarify this for anyone else<br>
stung by this in the future: <a href="http://wiki.bestpractical.com/view/ModifyCustomField">http://wiki.bestpractical.com/view/ModifyCustomField</a><br><br>The prior wiki description "<span class="argument-content"> This right allows the user to associate existing custom field<br>
values with the custom field's objects, e.g. tickets, users, etc." presupposes knowledge<br>of RT's schema. this read to me like "users with this right get to add previously defined<br>CFs to objects" (Configuration>Global>Custom Fields>*); clearly not something you want<br>
to grant to lowlier users, and so I had not. Whereas I imagine it's supposed to mean "you<br>get to set CF values for objects (which is done internally with some inter-table references.)"</span><br><br>To further clarify, given the name ModifyCustomField, my interpretation of the right<br>
prior to discovering the wiki entry was that it meant only users with this right could alter<br>the field *after it had been initially set on ticket creation.*<br><br><span class="argument-content"></span>-- <br>Cambridge Energy Alliance: Save money & the planet<br>
</div>