<div dir="ltr">Hello,<br><br>I was wondering why so many rights are conflated into this single privilege? Most other objects have separate rights for<br>Create, Modify &amp; Show, and while I admit it may not always be useful to separate these rights for users, I&#39;ve run into a<br>
few instances recently where I need for all three to be distinct...<br><br>As noted here&lt;<a href="http://www.gossamer-threads.com/lists/rt/users/77729?do=post_view_flat#77729">http://www.gossamer-threads.com/lists/rt/users/77729?do=post_view_flat#77729</a>&gt; I&#39;m allowing a script<br>
to create users, so that I can cut down on duplicate data and custom fields. I would prefer that the script only have the<br>ability to create users, and not modify them. On the flip-side, I&#39;d like to allow some folks the rights to alter the information<br>
for (customers ie.; non-privileged) users but not create users (nor tweak other privileged users).<br><br>Also note in the aforementioned message is that I want to give some users access to see this information, since it&#39;s no<br>
longer part of the ticket. ShowRequestor happily links to Admin/Users/Modify (there is no display only), but only if one<br>has AdminUsers. One can access that&nbsp; page without this right, but it seems only the UNIXy fields are displayed; though<br>
I am unable to determine why that is, there doesn&#39;t appear to be any differentiation in the source code. Before noticing<br>that the ShowRequestor title gets linkified, I was about to make a ShowUserLinked format style, which would display<br>
Real Names linked to Admin/Users/Modify; and perhaps this Usernameformat ought to be smart enough to instead take<br>one to a display only version of user information (read-only fields, sans submit) if one doesn&#39;t have Modify.<br>
<br>I can certainly try to implement some of this functionality myself, but most (especially the separation) will be difficult given<br>the current design of RT (plus my day job &amp; lack of familiarity with R guts), and I also wonder if these kinds of things might<br>
not be more generally useful. I realize that for some people, LDAP &amp; ExternalAuth might solve much of this, but we expect<br>to have a half-dozen privileged users and thousands of customer/ non-privileged users, so it seems best to stay within RT.<br>
<br>-- <br>Cambridge Energy Alliance: Save money &amp; the planet<br>
</div>