View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003757 | Composr | core_permission_management | public | 2019-01-09 21:50 | 2019-02-08 21:52 |
Reporter | Ennea | Assigned To | Chris Graham | ||
Severity | Minor-bug | ||||
Status | resolved | Resolution | fixed | ||
Product Version | |||||
Fixed in Version | |||||
Summary | 0003757: Super Moderator Permissions | ||||
Description | Super moderators are unable to change usergroups of members; despite being in the correct usergroup and having the privilege, they can't see the primary/secondary settings under member access levels. | ||||
Tags | No tags attached. | ||||
Time estimation (hours) | |||||
Sponsorship open | |||||
|
|
|
I can see the issue. It seems this privilege is mislabelled, it should be something like "Edit all usergroups regardless of leadership". There are other privileges associated with editing usergroup membership. I'm reviewing all the code, as it is looking a bit convoluted right now TBH. |
|
I have the "super moderator" box checked off in the group itself and it still doesn't work. Is there some other setting I may be missing? |
|
Right now you need these 2 privileges... Assume the identity/access of any other member Edit member profiles/accounts (including banning/validating/promoting them) The first is the highest privilege there is, below actually making someone a super-admin. They could use that privilege to make themselves a super-admin, e.g. using SU to an admin account, or changing their usergroup to an admin group. So only provide that privilege if you trust the users to not try and escalate themselves. Maybe you can trust them, often super-mods are fully trusted users you just don't want to be overwhelmed with all the admin controls, or you don't want them to have those controls but do trust them not to escalate. I am considering the idea of making it so the main privilege in this issue, or another one, does allow editing groups, so long as the groups added are not super-admins. But that could get thorny, because to be properly secure it would need to audit the permissions in other ways - e.g. if they add themselves to a group that happens to have Commandr access, that could be used for privilege escalation too. Sorry for the confusion caused by the incorrect privilege label described in this issue. |
|
That "assume identity" privilege did the trick, thank you! I didn't know that was required in order to let someone update a member's usergroups. Yes, the main concern to giving certain privileges to the super mod in question is overwhelming them with admin controls. Maybe certain privileges - at least those that may carry a high security risk - shouldn't be allowed assignment to groups that aren't super-admins? I can understand that some site owners may want to grant some admin privileges but not others to any group they wish, with that said, it's nice that the privileges are flexible in this way. But if I trust someone enough to give admin privs, I'd probably just make them an admin and tell them to ignore anything they don't understand - usually they're happy to do exactly that and leave the more complicated stuff to me lol Thanks again! |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-01-09 21:50 | Ennea | New Issue | |
2019-01-09 21:50 | Ennea | File Added: supermodperms.png | |
2019-01-10 01:32 | Chris Graham | Note Added: 0005897 | |
2019-01-13 01:22 | Guest | Note Added: 0005898 | |
2019-01-13 14:42 | Chris Graham | Note Added: 0005899 | |
2019-01-13 19:43 | Ennea | Note Added: 0005900 | |
2019-02-08 21:52 | Chris Graham | Assigned To | => Chris Graham |
2019-02-08 21:52 | Chris Graham | Status | non-assigned => resolved |
2019-02-08 21:52 | Chris Graham | Resolution | open => fixed |