Last edited 5 months ago
by Margit Link-Rodrigue

4.2 Permission manager

VisualWikitext
No edit summary
Tag: 2017 source edit
No edit summary
 
(8 intermediate revisions by the same user not shown)
Line 132: Line 132:
By assigning roles to a group, all users belonging to that group receive the rights of these roles. Roles are never assigned directly to users, but always to groups instead. Users are then assigned to one or more groups.
By assigning roles to a group, all users belonging to that group receive the rights of these roles. Roles are never assigned directly to users, but always to groups instead. Users are then assigned to one or more groups.
[[File:Manual:RightsRolesGroups.png|center|900x900px]]
[[File:Manual:RightsRolesGroups.png|center|900x900px]]
<br />
<br />As a result, the following administration pages play a role in rights management:
 
* [[Manual:Extension/BlueSpiceNamespaceManager|Namespace manager]]: In the wiki, user groups can be granted different permissions via roles in individual namespaces.
* [[Manual:Extension/BlueSpiceGroupManager|Group manager]]: Namespace permissions are assigned to user groups, not to individual users.
* [[Manual:Extension/BlueSpiceUserManager|User manager]]: Individual users are assigned to groups to obtain the permissions associated with the group.
* Permission manager: In the Permission manager, the user groups are assigned to their roles in the namespaces.
 
===The roles matrix===
===The roles matrix===
The permission manager consists of the group tree (1) and the role matrix (2):<br />
The permission manager consists of the group tree (1) and the role matrix (2):<span /><br />
[[File:Manual:PermissionManager2a.png|center|thumb|650x650px|Associating groups with roles in namespaces|link=Special:FilePath/Manual:PermissionManager2a.png]]
[[File:Manual:PermissionManager2a.png|center|thumb|650x650px|Associating groups with roles in namespaces|link=Special:FilePath/Manual:PermissionManager2a.png]]


 
<span><br /></span>
The '''group tree'''  shows all existing groups:
The '''group tree'''  shows all existing groups:


Line 144: Line 150:
*'''Subgroups of group "user":''' all groups that are defined on the wiki, eiter by default, by MediaWiki, or custom groups created in the [[Manual:Extension/BlueSpiceGroupManager|Group manager]] by an administrator. System groups, created by MediaWiki, can be hidden by unchecking the "Show system groups" checkbox above the tree.
*'''Subgroups of group "user":''' all groups that are defined on the wiki, eiter by default, by MediaWiki, or custom groups created in the [[Manual:Extension/BlueSpiceGroupManager|Group manager]] by an administrator. System groups, created by MediaWiki, can be hidden by unchecking the "Show system groups" checkbox above the tree.


 
<span><br /></span>
The columns in the '''role matrix''' are:
The columns in the '''role matrix''' are:


Line 160: Line 166:


===Default roles===
===Default roles===
By default, the Permission manager includes a number of predefined roles that serve most user needs. The individual permissions contained in a role can be seen by clicking the info icon in front of the role  name. It opens a dialog with a permissions list for the role.[[File:bot-permissions.png|center|650x650px|link=https://en.wiki.bluespice.com/wiki/File:bot-permissions.png]]
By default, the Permission manager includes a number of predefined roles that serve most user needs. The individual permissions contained in a role can be seen by clicking the info icon in front of the role  name. It opens a dialog with a permissions list for the role.[[File:bot-permissions.png|center|650x650px]]


*'''bot: '''exists to achieve recurring system actions. This role is assigned to the user BSMaintenance in Bluespice  via the group bot. The group bot should not be changed.
*'''accountselfcreate: ''' enables the automatic creation of new user accounts and is required for single-sign-on. You can assign this role, for example, to anonymous users who can create their own account.
*'''admin: '''Grants access to all administrative special pages and to all typical administrative features.
*'''reader''': Basic read access. Users can also edit their personal settings.
*'''maintenanceadmin: '''Similar to the ''admin'' role, but with extended admin rights for maintaining wiki integrity.
*'''commenter:''' allows the creation of discussion contributions and page ratings, but not of the pages themselves. The editor role includes all the rights of the commenter role. If a group has editor rights, it does not need special commenter rights.
*'''author: '''all permissions necessary for creating content on the wiki. Editing, moving, or deleting pages is not possible.
*'''author: '''all permissions necessary for creating content on the wiki. Editing, moving, or deleting pages is not possible.
*'''editor: '''create content, edit and delete content.
*'''editor: '''create content, edit and delete content.
*'''reviewer: ''' If you have activated the review function and, therefore, work draft pages in a namespace, there must be at least one group with the role of reviewer. By default, the group “reviewer” is available for this purpose. Only users in the reviewer role can approve draft pages. Reviewers generally need read, write and review rights via the corresponding three roles of reader, editor and reviewer. However, if you have not activated the review function in any namespace, you do not need this role in your wiki.
*'''reviewer: ''' If you have activated the review function and, therefore, work draft pages in a namespace, there must be at least one group with the role of reviewer. By default, the group “reviewer” is available for this purpose. Only users in the reviewer role can approve draft pages. Reviewers generally need read, write and review rights via the corresponding three roles of reader, editor and reviewer. However, if you have not activated the review function in any namespace, you do not need this role in your wiki.
*'''structuremanager: '''allows some actions for wiki maintenance such as moving pages, mass deleting pages or searching and replacing text, as well as renaming namespaces.
*'''accountmanager: '''enables the administration of user accounts. Since user accounts are managed independently of namespaces in the wiki, this role cannot be restricted to individual namespaces. Grayed-out namespaces have no meaning here as long as the role in the wiki itself is highlighted in green.
*'''accountmanager: '''enables the administration of user accounts. Since user accounts are managed independently of namespaces in the wiki, this role cannot be restricted to individual namespaces. Grayed-out namespaces have no meaning here as long as the role in the wiki itself is highlighted in green.
*'''structuremanager: '''allows some actions for wiki maintenance such as moving pages, mass deleting pages or searching and replacing text, as well as renaming namespaces.
*'''admin: '''Grants access to all administrative special pages and to all typical administrative features.
*'''accountselfcreate: ''' enables the automatic creation of new user accounts and is required for single-sign-on. You can assign this role, for example, to anonymous users who can create their own account.
*'''bot: '''exists to achieve recurring system actions. This role is assigned to the user BSMaintenance in Bluespice  via the group bot. The group bot should not be changed.
*'''commenter:''' allows the creation of discussion contributions and page ratings, but not of the pages themselves. The editor role includes all the rights of the commenter role. If a group has editor rights, it does not need special commenter rights.
*'''maintenanceadmin: '''Similar to the ''admin'' role, but with extended admin rights for maintaining wiki integrity.<br />
*'''reader''': Basic read access. Users can also edit their personal settings.<br />


== Restricting read permissions ==
== Restricting read permissions ==
It is possible to limit read permissions in a namespace by explicitely assigning the role reader to one or more particular groups. When users in other groups try to access a page in such a namespace, they will get a message that the permissions are denied.
It is possible to limit read permissions in a namespace by explicitely assigning the role ''reader'' to one or more particular groups. When users in other groups try to access a page in such a namespace, they will get a message that the permissions are denied.
[[File:Manual:permissions-denied.png|alt=Access denied|center|thumb|500x500px|Access denied]]
[[File:Manual:permissions-denied.png|alt=Access denied|center|thumb|500x500px|Access denied]]
While a user cannot access the content of the page, the wiki still shows links to these pages to all users in some contexts, even if a user does not have permissions to access the page. The following lists show which extensions or functionalities do not show links to restricted pages  — because they are permissions-aware — and where the links are shown regardless of permissions.
While a user cannot access the content of the page, the wiki still shows links to these pages to all users in some contexts, even if a user does not have permissions to access the page content itself.  
 
<span><br /></span>
The following lists show which extensions or functionalities do not show links to restricted pages  — because they are permissions-aware — and where the links are shown regardless of permissions.


=== Exensions  that are permissions-aware ===
=== Exensions  that are permissions-aware ===
Query results and page lists provided by the following extensions do not show links to pages to which the current user has no access on the namespace level:
Query results and page lists provided by the following extensions do not show links to pages to which the current user has no access on the namespace level:
<br />
<span /><br />
* [[Manual:Extension/BlueSpiceExtendedSearch|ExtendedSearch]] (and functionality based on Extended Search in general, e.g. [[Manual:Extension/BlueSpiceTagSearch|TagSearch]], [[Manual:Extension/BlueSpiceExtendedFilelist|ExtendedFilelist]]).
* [[Manual:Extension/BlueSpiceExtendedSearch|ExtendedSearch]] (and functionality based on Extended Search in general, e.g. [[Manual:Extension/BlueSpiceTagSearch|TagSearch]], [[Manual:Extension/BlueSpiceExtendedFilelist|ExtendedFilelist]]).
*[[Reference:Semantic MediaWiki|Semantic MediaWiki]]
*[[Reference:Semantic MediaWiki|Semantic MediaWiki]]
*[[Manual:Extension/BlueSpiceInsertMagic|TopList]]
*[[Manual:Extension/BlueSpiceInsertMagic|TopList]]<span /><br />
<br />
=== Extensions and special pages that are not permissions-aware ===
=== Extensions and special pages that are not permissions-aware ===
Extensions that provide links lists do not hide links to read-restricted pages to the affected users. Examples:
Extensions that provide page lists and that do not hide links to read-restricted pages to the affected users. Examples:
<br />
<span /><br />
*[[Reference:DynamicPageList3|DynamicPageList3]]
*[[Reference:DynamicPageList3|DynamicPageList3]]
*[[Manual:Extension/BlueSpiceSmartList|SmartList]]
*[[Manual:Extension/BlueSpiceSmartList|SmartList]]
* [[Reference:BlueSpiceWatchList|WatchList]] (both the tag and the special page)
* [[Reference:BlueSpiceWatchList|WatchList]] (both the tag and the special page)
<br />
<span /><br />
In general, all MediaWiki special pages do not check permissions and therefore list these pages to the affected users. Most common examples:
In general, all MediaWiki special pages do not check permissions and therefore list these pages for the affected users. Most common examples:
<br />
<span /><br />
* Special:All pages
* Special:All pages
* Special:RecentChanges
* Special:RecentChanges
* Special:Bookshelf  ('''Note:''' If this is an issue, you can limit access to the namespace ''Book'' to selected groups. The page ''Special:Bookshelf'' then won't show any links to books to users who do not have access to the Books namespace. Links to individual books can then be provided on various portal pages as needed).
* Special:Bookshelf  ('''Note:''' If this is an issue, you can limit access to the namespace ''Book'' to selected groups. The page ''Special:Bookshelf'' then won't show any links to books to users who do not have access to the ''Book'' namespace. Links to individual books can then be provided on various portal pages as needed).
* Category pages: All pages in the namespace ''Category''
* Category pages: All pages in the namespace ''Category''
<br />
 
=== Limited transclusion ===
If you explicitely assign the ''reader'' role (or any other role that contains the ''read'' permission) in a namespace to a group or groups, that namespace is automatically configured so that its content cannot be transcluded. This is for security reasons, since MediaWiki does not check permissions when transcluding content.
 
==Technical info==
==Technical info==
===Logging===
===Logging===
Line 205: Line 216:
These logs are available only to wiki administrators (users in groups with the role ''admin'').
These logs are available only to wiki administrators (users in groups with the role ''admin'').
==Configuration ==
==Configuration ==
All changes to the role matrix  are backed up. By default, the last 5 backups are kept. This limit can be changed in [[Manual:Extension/BlueSpiceConfigManager|Config manager]], under extension BlueSpicePermissionManager.<br />{{#dpl:title=Manual:Extension/BlueSpiceConfigManager|include=#BlueSpicePermissionManager}}
All changes to the role matrix  are backed up. By default, the last 5 backups are kept. This limit can be changed in [[Manual:Extension/BlueSpiceConfigManager|Config manager]], under extension BlueSpicePermissionManager.<span /><br />{{#dpl:title=Manual:Extension/BlueSpiceConfigManager|include=#BlueSpicePermissionManager}}
 


<span><br /></span>
{{Box Links-en|Topic1=[[Reference:BlueSpicePermissionManager]]|Topic2=[[Manual:Extension/BlueSpiceGroupManager|Group manager]]}}
{{Box Links-en|Topic1=[[Reference:BlueSpicePermissionManager]]|Topic2=[[Manual:Extension/BlueSpiceGroupManager|Group manager]]}}
{{translation}}
{{translation}}

Latest revision as of 17:38, 23 July 2024


The permission manager can be accessed from the Global actions menu under Administration > Permissions. This link loads the page Special:PermissionManager.

There are four different permission settings. The default setting is "Private wiki". If you want to grant different permissions in different namespaces, the setting "Custom setup" is required.

Permissions manager
Permissions manager

Settings

An administrator can choose between three types of settings. The setting Private Wiki is activated by default.

Permission type Description Special permissions
Public wiki The wiki is visible to and editable by anyone, including anonymous users (that means users that are not logged in).
  • All users have edit rights by default.
  • To approve a page (if the approval mechanism is activated in a namespace), the groups "editor" and "reviewer" must be assigned to a user.
  • To manage the wiki (administrative tasks), the group "sysop" must be assigned to a user.
 Sonderverrechtung: [1]
// Anonymous and logged-in users can read and edit
$this->groupRoles['*']['reader'] = true;
$this->groupRoles['*']['editor'] = true;
Protected wiki The wiki is visible to anyone. Only logged-in users can edit the wiki.
  • All users have edit rights by default.
  • To approve a page (if the approval mechanism is activated in a namespace), the groups "editor" and "reviewer" must be assigned to a user.
  • To manage the wiki (administrative tasks), the group "sysop" must be assigned to a user.
 Sonderverrechtung:[1]:
// Anonymous users can read, logged-in users can edit
$this->groupRoles['*']['reader'] = true;
$this->groupRoles['*']['editor'] = false;
$this->groupRoles['user']['editor'] = true;
Private wiki Only logged-in users can view and edit the wiki.
  • Logged-in users only have veiw permissions.
  • Important! To edit a page, users must be assigned to the "editor" group manually.
  • To approve a page (if the approval mechanism is activated in a namespace), the groups "editor" and "reviewer" must be assigned to a user.
  • To manage the wiki (administrative tasks), the group "sysop" must be assigned to a user.
 Sonderverrechtung:[1]
// Only logged-in users can read. The group "editor" has to be manually assigned to users.
$this->groupRoles['*']['reader'] = false;
$this->groupRoles['*']['editor'] = false;
$this->groupRoles['user']['reader'] = true;
$this->groupRoles['user']['editor'] = false;
$this->groupRoles['editor']['editor'] = true;
$this->groupRoles['sysop']['editor'] = true;
Custom setup

(BlueSpice pro)

Roles and groups are assigned by an administrator. This is necessary if different namespaces need to have different user rights. See the next section for more info.
  1. ↑ 1.0 1.1 1.2 Global permissions (modified by the special permissions shown in the table above):
    'bureaucrat' => [ 
'accountmanager' => true 
],
'sysop' => [
'reader' => true,
'editor' => true,
'reviewer' => true,
'admin' => true
],
'user' => [ 'editor' => true ],
'editor' => [
'reader' => true,
'editor' => true
],
'reviewer' => [
'reader' => true,
'editor' => true,
'reviewer' => true
Note:In BlueSpice pro Cloud, it is not possible to assign edit, comment, or upload rights to anonymous users.

Custom setup

Die Tabelle zeigt typische Standardeinstellungen für eine einfache Benutzerverwaltung:

Group Default roles Purpose of the group Suggested rolees
anonymous user (*) - Determines if anonymous users can read wiki pages. (no role assignment) or reader
user reader, editor Determines the rights authenticated users have if they don't belong to any other groups. All groups except for anonymous users initially inherit permissions from this group. reader or

reader, editor

editor (von user geerbt),

editor

Group members can edit the wiki. (editor)*
reviewer (von user geerbt), reviewer Group members can approve page revisions if the approval feature is activated. reviewer
sysop (von user geerbt), editor, admin Grants administrator rights to the wiki.

Included in roles: admin, maintenanceadmin

(editor)*, admin
* can be inherited through the group "user"
Note:If you have saved the personalized settings at least once and then switch back to a "protected" or "private" wiki, you do not lose your latest personalized settings. You can simply resave the latest saved settings to switch back to a wiki with personalized permissions.


About role-based permissions

Roles represent a collection of individual permissions that are necessary to perform certain functions in the wiki. For example, for a user who is supposed to only read the wiki, many permissions in addition to the "read" permission are needed: The ability to change their own settings, to search the wiki, to view page ratings, and so on.

All permissions that make up a logical group are encapsulated in a role, in this example the role "reader". If wiki administrators want to grant read-only rights to a user group, they only need to assign that group the "reader" role, instead of assigning many individual permissions that are needed to create a "read"-user.

By assigning roles to a group, all users belonging to that group receive the rights of these roles. Roles are never assigned directly to users, but always to groups instead. Users are then assigned to one or more groups.

Manual:RightsRolesGroups.png


As a result, the following administration pages play a role in rights management:

  • Namespace manager: In the wiki, user groups can be granted different permissions via roles in individual namespaces.
  • Group manager: Namespace permissions are assigned to user groups, not to individual users.
  • User manager: Individual users are assigned to groups to obtain the permissions associated with the group.
  • Permission manager: In the Permission manager, the user groups are assigned to their roles in the namespaces.

The roles matrix

The permission manager consists of the group tree (1) and the role matrix (2):

Associating groups with roles in namespaces


 The group tree shows all existing groups:

  • Group "*": all non-logged-in (anonymous) users
  • Group "user": all logged-in users, the default group for all users
  • Subgroups of group "user": all groups that are defined on the wiki, eiter by default, by MediaWiki, or custom groups created in the Group manager by an administrator. System groups, created by MediaWiki, can be hidden by unchecking the "Show system groups" checkbox above the tree.


 The columns in the role matrix are:

  • Role information (info icon): Clicking the icon shows all the permissions in a role. This list is exportable.
  • Role name
  • Wiki: Assignment of a role to the entire wiki. By assigning the role in this column, a user group gets permissions in this role on the wiki (all namespaces).
  • Individual namespaces: The following columns list every (applicable) namespace on the wiki.
    • Roles can be assigned to individual namespaces. For example, the group user can get the editor role only in the namespace Public. Users in this group cannot edit content in any other . By granting a role to a particular group in a particular namespace, means that all other groups will lose permissions from this role, eg. granting role "reader" in namespace "Private" to group "sysop" means that all users in any other groups won't be able to read pages in "Private" namespace, even if they have "reader" role granted on the wiki level ("Wiki" column).
    • The same role can be granted to multiple groups for the same namespace.
    • Additional namespaces can be added in the matrix by clicking on the arrow in table header, then "Columns". Then the namespaces can be selected.

Role inheritance

By default, all roles granted to the (*) group will be granted to the user group, and all roles granted to the user group are granted to its subgroups. If a group inherits the role from an upper-level group field, this is indicated in the role matrix with a green background, but the checkbox is empty.

Default roles

By default, the Permission manager includes a number of predefined roles that serve most user needs. The individual permissions contained in a role can be seen by clicking the info icon in front of the role name. It opens a dialog with a permissions list for the role.

bot-permissions.png
  • accountselfcreate: enables the automatic creation of new user accounts and is required for single-sign-on. You can assign this role, for example, to anonymous users who can create their own account.
  • reader: Basic read access. Users can also edit their personal settings.
  • commenter: allows the creation of discussion contributions and page ratings, but not of the pages themselves. The editor role includes all the rights of the commenter role. If a group has editor rights, it does not need special commenter rights.
  • author: all permissions necessary for creating content on the wiki. Editing, moving, or deleting pages is not possible.
  • editor: create content, edit and delete content.
  • reviewer: If you have activated the review function and, therefore, work draft pages in a namespace, there must be at least one group with the role of reviewer. By default, the group “reviewer” is available for this purpose. Only users in the reviewer role can approve draft pages. Reviewers generally need read, write and review rights via the corresponding three roles of reader, editor and reviewer. However, if you have not activated the review function in any namespace, you do not need this role in your wiki.
  • structuremanager: allows some actions for wiki maintenance such as moving pages, mass deleting pages or searching and replacing text, as well as renaming namespaces.
  • accountmanager: enables the administration of user accounts. Since user accounts are managed independently of namespaces in the wiki, this role cannot be restricted to individual namespaces. Grayed-out namespaces have no meaning here as long as the role in the wiki itself is highlighted in green.
  • admin: Grants access to all administrative special pages and to all typical administrative features.
  • bot: exists to achieve recurring system actions. This role is assigned to the user BSMaintenance in Bluespice via the group bot. The group bot should not be changed.
  • maintenanceadmin: Similar to the admin role, but with extended admin rights for maintaining wiki integrity.

Restricting read permissions

It is possible to limit read permissions in a namespace by explicitely assigning the role reader to one or more particular groups. When users in other groups try to access a page in such a namespace, they will get a message that the permissions are denied.

Access denied
Access denied

While a user cannot access the content of the page, the wiki still shows links to these pages to all users in some contexts, even if a user does not have permissions to access the page content itself.


The following lists show which extensions or functionalities do not show links to restricted pages — because they are permissions-aware — and where the links are shown regardless of permissions.

Exensions that are permissions-aware

Query results and page lists provided by the following extensions do not show links to pages to which the current user has no access on the namespace level:

Extensions and special pages that are not permissions-aware

Extensions that provide page lists and that do not hide links to read-restricted pages to the affected users. Examples:


In general, all MediaWiki special pages do not check permissions and therefore list these pages for the affected users. Most common examples:

  • Special:All pages
  • Special:RecentChanges
  • Special:Bookshelf (Note: If this is an issue, you can limit access to the namespace Book to selected groups. The page Special:Bookshelf then won't show any links to books to users who do not have access to the Book namespace. Links to individual books can then be provided on various portal pages as needed).
  • Category pages: All pages in the namespace Category

Limited transclusion

If you explicitely assign the reader role (or any other role that contains the read permission) in a namespace to a group or groups, that namespace is automatically configured so that its content cannot be transcluded. This is for security reasons, since MediaWiki does not check permissions when transcluding content.

Technical info

Logging

Every change to the roles is logged in Special:Log, in the Permission Manager log . These logs are available only to wiki administrators (users in groups with the role admin).

Configuration

All changes to the role matrix are backed up. By default, the last 5 backups are kept. This limit can be changed in Config manager, under extension BlueSpicePermissionManager.

  • Backup limit: Sets the number of backups for the permissions manager. Each time the page Special:PermissionManager is saved, a backup is created. If the backup limit is set to 5, the last five versions of the permissions configuration are saved as backups.

Related info


Technical Reference: BlueSpicePermissionManager


To submit feedback about this documentation, visit our community forum.

Retrieved from "https://en.wiki.bluespice.com/w/index.php?title=Manual:Extension/BlueSpicePermissionManager&oldid=9897"