Manual:$wgRevokePermissions
<translate> User rights, access control and monitoring</translate>: $wgRevokePermissions | |
---|---|
Permission keys revoked from users in each group. |
|
<translate> Introduced in version:</translate> | 1.16.0 (r52083) |
<translate> Removed in version:</translate> | <translate> still in use</translate> |
<translate> Allowed values:</translate> | (Complex array of boolean values.) |
<translate> Default value:</translate> | [] |
<translate> Other settings:</translate> <translate> Alphabetical</translate> | <translate> By function</translate> |
Details
$wgGroupPermissions allows setting permissions for user groups.
$wgRevokePermissions
allows revocation of any of those permissions.
Revoking a right with $wgRevokePermissions
takes precedence over granting it with $wgGroupPermissions
.
If the right is revoked for even one of the user's groups, they will not have it, regardless of whether it's explicitly permitted by other groups.
- Example
$wgRevokePermissions['sysop']['editinterface'] = true;
- Result is (when viewing Special:ListGroupRights)
Edit the user interface (editinterface
)
This acts the same way as $wgGroupPermissions , except that if the user is in a group here, the permission will be removed rather than added. A good use-case for this setting is in conjunction with $wgAutopromote and APCOND_BLOCKED to further restrict the rights of blocked users. Another use-case could be the creation of other "blocked groups" where a sysop can (via $wgAddGroups ) add a user to a group to allow them to edit pages normally, but prevent them from being able to move pages.