Addional Information (http://www.simplemachines.org/community/index.php?topic=332411.0)
When you uncheck the Access to Moderation Centre Permission group_id=2 Global Moderator can still access the Moderation Centre.
If they are granted the permission moderate_forum then they can still see the mod center
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.
I forgot about this since i posted it 4 - 5 months ago lol.
Thanks for adding this norv :)
The core determinant of whether it should be shown is given by this in setupMenuContext():
$context['allow_moderation_center'] = $context['user']['can_mod'];
In turn that's driven by this in Load.php
'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.
/me thinks this is by design, even if not expected.
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
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.
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.
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.
Quote from: Arantor on December 04, 2009, 09:54:07 AM
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.
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.
/me notes more in the bug report.
But even tho their disabled core features, they still have the permissions. o.O
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)
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
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)
A behavior that makes sense IMO is to only consider "active" permissions when computing effects. "Active permissions" meaning permissions of active features.
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.
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?
Quote from: α¢αηѕ on December 06, 2009, 08:40:21 AM
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.
Quote
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.
Great, Hopefully its fixed in RC3 or Final
I've posted some more on the bug report for this one, as I'm really not sure the best approach to take here.
Quote from: Arantor on December 07, 2009, 07:54:31 AM
I've posted some more on the bug report for this one, as I'm really not sure the best approach to take here.
Mmm, I was taking note on some of the suggestions you where making on the official bug report in the bug tracker, sep I cannot comment as well :(
Quoting the text here for you to reply to:
QuoteRandom question: if access is not granted to the moderation center by the overarching permission, should that simply be it?
For example, a moderator without access but still have access to moderate_board still has access to the center.
I have a patch that will actually take into account the hidden permissions correctly, though it doesn't (currently) take it into account on the Show Permissions page. But it occurs to me that moderate_board does grant access_mod_center implicitly.
While I like what you're suggesting, Norv, I don't think it's something we should change now. For 2.1, perhaps, but definitely not this stage.
As I see it, we have three routes.
1. Make access to mod center dependent ONLY on access_mod_center, meaning the show and isAllowedTo checks on that only.
2. Go with something akin to the (IMHO) hackish patch I have that disables hidden permissions. This would also, however, tidy up something for modders such that they can put all the hideable permissions in a single place.
3. What you've suggested, have permissions implicitly triggering other permissions in a UI-visible way. (Right now, the implicit trigger is still there, but not visible)
I don't have a problem with patching for option 1 - it is 'expected' if not entirely 'desirable' behaviour. 2... well, I already have a patch that does most of the work here and 'seems' to work. 3, I have to argue is something we would at best put back to 2.1.
(Though the patch does the view permissions page too)
Do you think you can add this as a comment in my place.
What about breaking up the Moderation Centre like we have with the Administration centre.
In 2.0 RC1.2, the last bug i reported was Group Moderators can see the WHOLE moderation centre, when really all they should see is their group requests. AFAIK this has been fixed.
Example: Why not if the Warnings system is disabled, you do not see the Recent watched members blocks.
What I'm saying is certain permissions activate the blocks instead of one permission activates all.
There is no need to add the comment, this topic is already linked into the bug report, thus this topic will most likely be verified as well by the devs when they analyse the situation.
Thank you for the point added!
Has the patch for this one been reviewed? Are there any issues with the provided patch? (NB, I don't know if it's still the case in RC3... I never retested it since the bug is still open, nor have I retested the patch from 3+ months ago on it)
Fixed with Revision 9884.
I see this is fixed, but I have to say I disagree with the logic of the solution used. I understand why it was done, but here's my $0.02c on it.
The reason I proposed the 'overkill' is because it fixes the root cause: permissions being given for disabled features that have knock-on effects. Simply checking the permissions isn't enough; the permissions are still being granted in this case. You're just doing other checks that overrides that factor. I still think actually disabling them is a cleaner solution, especially if you later extend Core Features with other stuff.
Having the disabling factor as well also gives customisation authors who would extend SMF with entries in Core Features somewhere to hook into.
*shrug* You've fixed the immediately visible bug, can't fault you on your energy and knowledge there, but I think you've fixed the symptom, not the underlying cause.