Is it possible for a user-defined group to get the “AdminUser”
right but only for selected users? i.e. I’ve got a U-D group “support”.
I’d like members of the Support group to be able to modify user
information for unprivileged users, but not for members of other
user-defined groups.
In the groups rights screen for the support group
(Configuration->Groups->Support) I’ve given the support group the
following rights on the Unprivileged group:
AdminGroup
AdminGroupMembership
ModifyOwnMembership
SeeGroup
…but support members are still unable to modify user information for
unpriv’d users. Am I missing something?
/Ole Craig
Security Engineer
303-381-3802 (main support hotline)
303-381-3824 (my direct line)
303-381-3801 (fax)
www.stillsecure.com
. . .
Is it possible for a user-defined group to get the "AdminUser"
right but only for selected users? i.e. I’ve got a U-D group “support”.
I’d like members of the Support group to be able to modify user
information for unprivileged users, but not for members of other
user-defined groups.
Sorry. That’s not currently possible.
Jesse Vincent wrote:
Is it possible for a user-defined group to get the "AdminUser"
right but only for selected users? i.e. I’ve got a U-D group “support”.
I’d like members of the Support group to be able to modify user
information for unprivileged users, but not for members of other
user-defined groups.
Sorry. That’s not currently possible.
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
We’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions
Ole,
Although we subscribe to the "group" method of assigning privileges
as opposed to the individual “users”, for something like this, you might
just want to create a list of certain users and make them superusers and
they can do anything. Not consistent with our philosophy, but sometimes
you have to break a rule to get the job done, if the job is that important.
Kenn/LBNL
Is it possible for a user-defined group to get the "AdminUser"
right but only for selected users? i.e. I’ve got a U-D group “support”.
I’d like members of the Support group to be able to modify user
information for unprivileged users, but not for members of other
user-defined groups.
Sorry. That’s not currently possible.
Urk. That's... dismaying. Has anyone ever asked before? I
couldn’t find anything in the archives, but it seems like an obvious
“want” feature to me, in that I’d like my support staff brethren to be
able to add notes about particular customers and update phone numbers
and such, but I don’t want them to modify the user records for the
executive team (for instance.)
In re-reading my screed I realize that my logic was overly
fuzzified during verbalization: support staff should be able to modify
the user record of any member of a particular group (regardless of that
user’s other group memberships) as long as the support group has been
given the appropriate rights for the target group.
Given the immediacy and brevity of Jesse's answer, I suspect
that’s a distinction that fails to make a difference, but clearer logic
is always useful. Particularly since I may have to try and hack the
functionality in somehow, so I’m attempting to flesh out the equivalence
cases…
/Ole Craig
Security Engineer
303-381-3802 (main support hotline)
303-381-3824 (my direct line)
303-381-3801 (fax)
www.stillsecure.com
. . .
Is it possible for a user-defined group to get the "AdminUser"
right but only for selected users? i.e. I’ve got a U-D group “support”.
I’d like members of the Support group to be able to modify user
information for unprivileged users, but not for members of other
user-defined groups.
Sorry. That’s not currently possible.
Urk. That's... dismaying. Has anyone ever asked before? I
couldn’t find anything in the archives, but it seems like an obvious
“want” feature to me, in that I’d like my support staff brethren to be
able to add notes about particular customers and update phone numbers
and such, but I don’t want them to modify the user records for the
executive team (for instance.)
You’re welcome to have your money back 
Seriously, though, it’s a
feature that I’d find useful, but isn’t something we’ve ever needed in
house or at any customer site. If you hack it together in a way that
would be a sane RT core change, it’s something I’d be happy to see in a
future release.
In re-reading my screed I realize that my logic was overly
fuzzified during verbalization: support staff should be able to modify
the user record of any member of a particular group (regardless of that
user’s other group memberships) as long as the support group has been
given the appropriate rights for the target group.
It was clear. More often, I see this requirement as "Customer service
should be able to modify user attributes for unprivileged users. Your
description is a reasonable generalization.
Given the immediacy and brevity of Jesse's answer, I suspect
that’s a distinction that fails to make a difference, but clearer logic
is always useful. Particularly since I may have to try and hack the
functionality in somehow, so I’m attempting to flesh out the equivalence
cases…
The brevity was actually likely due to the fact that I’m crunching on
way too many things but still want to be at least marginally useful to
the community. It seemed like I could give you a “nope, it’s not there”.
I didn’t mean it to sound abrasive. Sorry if I did.
Best,
Jesse
You’re welcome to have your money back Seriously, though, it’s a
feature that I’d find useful, but isn’t something we’ve ever needed in
house or at any customer site. If you hack it together in a way that
would be a sane RT core change, it’s something I’d be happy to see in a
future release.
I’ll see what I can come up with. It’ll be a good excuse to dust off my
Camel. 
[…]
It was clear. More often, I see this requirement as "Customer service
should be able to modify user attributes for unprivileged users. Your
description is a reasonable generalization.
Yup, I was attempting to generalize into the existing ACL paradigm as
much as possible. (Plus we’re probably going to have multiple levels of
users, and some levels should be able to modify others – partners,
resellers, OEM… &etc.)
[…]
The brevity was actually likely due to the fact that I’m crunching on
way too many things but still want to be at least marginally useful to
the community. It seemed like I could give you a “nope, it’s not there”.
I didn’t mean it to sound abrasive. Sorry if I did.
Not at all! I was just thinking that since you replied so quickly and
definitively (and without any of your usual hints to the effect of “but
if you wanted to do here’s where to
look”) …it seemed unlikely that my restatement would provoke a
different response. No abrasion was inferred or suffered, and my
apologies for jogging your elbow mid-juggle. (Or mid-crunch.)
Thanks for a great toolkit,
Ole
/Ole Craig
Security Engineer
303-381-3802 (main support hotline)
303-381-3824 (my direct line)
303-381-3801 (fax)
www.stillsecure.com
. . .