[4058]Access to Mod Centre Permission doesn't apply to group_id=2 (Global Mod)

[Acans]

Addional Information

When you uncheck the Access to Moderation Centre Permission group_id=2 Global Moderator can still access the Moderation Centre.

[SleePy]

If they are granted the permission moderate_forum then they can still see the mod center

[Norv]

I can replicate still this on the latest svn: a standard global moderator group (id_group = 2) can access the moderation center, even though they don't have "Access the moderation center" permission. (they don't have "Moderate forum members" either).

ETA: tracked as http://dev.simplemachines.org/mantis/view.php?id=4058, to allow easier feedback and eventually decision on it.

[Acans]

I forgot about this since i posted it 4 - 5 months ago lol.

Thanks for adding this norv

[Arantor]

The core determinant of whether it should be shown is given by this in setupMenuContext():

Code Select Expand

$context['allow_moderation_center'] = $context['user']['can_mod'];

In turn that's driven by this in Load.php

Code Select Expand

'can_mod' => allowedTo('access_mod_center') || (!$user_info['is_guest'] && ($user_info['mod_cache']['gq'] != '0=1' || $user_info['mod_cache']['bq'] != '0=1')),

The key determinants here are gq and bq; group query, a cache for the group/permissions access that's cached for the user, and bq, for boards they are allowed to moderate.

Going back into it, this is pulled in rebuildModCache() in Subs-Auth.php, and ultimately is driven by a user having either manage membergroups or moderate forum/board - if they can moderate a single board, or manage membergroups, they require access to the moderation center implicitly.

* Arantor thinks this is by design, even if not expected.

[Acans]

On a Fresh install of 2.0 RC2, I removed ALL Permissions from the group_id=2 group, and it can still view the Moderation Centre. You can't use the Search feature, Posts, View the memberlist, your own profile, ect. But you still get a golden ticket into the Moderation Centre by being in group_id=2.

www.dev.acans.org/2.0

User: gmod
Password: globalmoderator

[Arantor]

Both general and from every profile?

Hmm, that suggests then it's pulling from the cache in the session. Note that there's still some moderation ability left in that account, e.g. seeing watched members.

[Acans]

Sorry to disappoint you, but I have left no permission checked, on the permissions page it even says 0.

Take a look for your self, check your inbox.

[Arantor]

Something else is hokey here.

Admin > Members > Board Permissions > Default > clearly shows Gmod as having 5 permissions.

Also take a look at action=profile;area=permissions;u=2 - shows several permissions.

[Acans]

Admin > Members > Board Permissions > Default > clearly shows Gmod as having 5 permissions.

Those are hidden permissions.

Go into the Default profile, than global mods and open all the drop downs, theirs nothing checked.

[Arantor]

Ah, I see. They're permissions that the group has but not accessible because they're for the calendar and post moderation - which are currently disabled features.

* Arantor notes more in the bug report.

[Acans]

But even tho their disabled core features, they still have the permissions. o.O

[Arantor]

Yeah, because the permissions are still defined and still set up when SMF is installed.

Otherwise if you turned them on, it would be weird because the global moderator would have no rights to change things out of the box, which seems even less logical behaviour (IMHO)

[Acans]

How about the global moderator doesn't get these permissions till the feature has been activated.

example, when post moderation is activated, give group_id=2 following permissions.

When post moderation is disabled, remove these permissions from group_id=2

[Arantor]

So if you don't grant the permissions, you actually complicate matters a lot more.

Consider the following scenario:
* Enable post moderation
* (permissions get added)
* Disable permission for global moderator
* time passes....
* Disable post moderation
* time passes....
* Enable post moderation

Now you have the unexpected behaviour that the permission gets granted again. That's why permissions are not touched when enabling/disabling those features (actually much like mods)

[Norv]

A behavior that makes sense IMO is to only consider "active" permissions when computing effects. "Active permissions" meaning permissions of active features.

[Arantor]

Hmm. There's nothing in the permissions table IIRC about active or not, the permission is either listed or not.

I suppose a check could be added in the permissions functions (allowedTo, isAllowedTo, boardsAllowedTo) to check for active features, but you'd also have to explicitly define which permissions were driven by which functions, and likely have to either push that into the DB somewhere, or lay them all out in the three functions.

[Acans]

Thats understandable.

But getting back to the bug at hand how do you think it will be fixed since these permissions grant access to the moderation centre.

Have it set so if Post Moderation feature is turned off, the following permissions don't grant access to the moderation centre?

Also for a British person you spell centre wrong, or are you respecting that in SMF its called Center?

[Arantor]

Thats understandable.

But getting back to the bug at hand how do you think it will be fixed since these permissions grant access to the moderation centre.

Have it set so if Post Moderation feature is turned off, the following permissions don't grant access to the moderation centre?

It's not just post moderation - it's also the calendar. Solution is to rewrite part of the code I referred to above, rebuildModCache() in Subs-Auth.php.

Also for a British person you spell centre wrong, or are you respecting that in SMF its called Center?

Probably a typo; e & r are so close together.

[Acans]

Great, Hopefully its fixed in RC3 or Final