[Rt-devel] AdminUsers superposition

Jerrad Pierce jpierce at cambridgeenergyalliance.org
Tue Aug 26 11:49:06 EDT 2008


I was wondering why so many rights are conflated into this single privilege?
Most other objects have separate rights for
Create, Modify & Show, and while I admit it may not always be useful to
separate these rights for users, I've run into a
few instances recently where I need for all three to be distinct...

As noted here<
I'm allowing a script
to create users, so that I can cut down on duplicate data and custom fields.
I would prefer that the script only have the
ability to create users, and not modify them. On the flip-side, I'd like to
allow some folks the rights to alter the information
for (customers ie.; non-privileged) users but not create users (nor tweak
other privileged users).

Also note in the aforementioned message is that I want to give some users
access to see this information, since it's no
longer part of the ticket. ShowRequestor happily links to Admin/Users/Modify
(there is no display only), but only if one
has AdminUsers. One can access that  page without this right, but it seems
only the UNIXy fields are displayed; though
I am unable to determine why that is, there doesn't appear to be any
differentiation in the source code. Before noticing
that the ShowRequestor title gets linkified, I was about to make a
ShowUserLinked format style, which would display
Real Names linked to Admin/Users/Modify; and perhaps this Usernameformat
ought to be smart enough to instead take
one to a display only version of user information (read-only fields, sans
submit) if one doesn't have Modify.

I can certainly try to implement some of this functionality myself, but most
(especially the separation) will be difficult given
the current design of RT (plus my day job & lack of familiarity with R
guts), and I also wonder if these kinds of things might
not be more generally useful. I realize that for some people, LDAP &
ExternalAuth might solve much of this, but we expect
to have a half-dozen privileged users and thousands of customer/
non-privileged users, so it seems best to stay within RT.

Cambridge Energy Alliance: Save money & the planet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/rt-devel/attachments/20080826/11b970a5/attachment-0001.htm 

More information about the Rt-devel mailing list