Difference between revisions of "Manual:Extension/BlueSpicePermissionManager"

[unchecked revision][quality revision]
(Tag: 2017 source edit)
 

What is BlueSpicePermissionManager?

Accessing the Permission manager[edit | edit source]

BlueSpicePermissionManager offers easy and user-friendy way to manage user permissions on the wiki.

Where to find BlueSpicePermissionManager[edit | edit source]

PermissionManager1a.png

BlueSpicePermissionManager is available from the left navigation, under "Global actions" tab, under the section "Management", or by navigating directly to Special:PermissionManager

Using the BlueSpicePermissionManager

To manage permissions, you use the Permission manager. It is located under Global actions > Management > Permission manager. This links to the page Special:PermissionManager.

Role-based permissions[edit | edit source]

The role system[edit | edit source]

Since BlueSpice version 3.0, roles,
Watch now: Rights management (10:13)
Watch now: Rights management

In BlueSpice 3, roles were introduced as a way to manage wiki user rights, are introduced. The main intention of using roles is to simplify rights management and make it more straigh-forward.

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

All permissions that make up a logical group , are encapsulated to in a role, in this example to the role "reader". This way, if If wiki admins want to grant ability to have read-only rights on the wiki to a user group, they only need to assign that group the "reader" role, instead of assigning tens of different rights, which would such user group require.

Other functions on the wiki would also rights required for them encapsulated in a role.

By assigning role many individual permissions that are needed to create a "read"-user.

By assigning roles to a group, all users belonging to that group will receive rights contained in the role.

BlueSpicePermissionManager, since version 3.0, allows managing role assignment, instead of permission assignment as was the case in previous versions.

Default roles

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.

How users get their user rights

The roles matrix[edit | edit source]

By default BlueSpicePermissionManager offers a number of pre-defined roles that are created to serve most of the user needs on the wiki:

  • bot - role that should be typically assigned only to the "bot" group.
  • admin - role that contains all available rights, and should be assigned only to wiki-admin groups.
  • maintenanceadmin - very similar to "admin" role, used for user groups that are responsible for maintaining wiki integrity
  • author - this role contains all permissions necessary for creating content on the wiki.
  • editor - role meant for user groups that are able to not only create own content, but to edit, create reviews and delete all content of the wik
  • reviewer - role that allows users to perform all reviewing actions on the wiki
  • accountmanager - role means for users that will manage user accounts
  • structuremanager - this role allows users to manage the structure of the wiki - move (rename) pages, create and delete namespaces...
  • reader - role that allows basic read-only access to the wiki
  • accountselfcreate - this role must be assinged to the "*" groups, in order to allow users to create user accounts by themselves
  • commenter - role for users that cannot create and edit content, but can comment on the existing content

Layout of BlueSpicePermissionManager[edit | edit source]

Adding namespaces to the role matrix

BlueSpicePermissionManager consists of:

the group tree on the left - showing all the groups available on the wiki in the hierarchy. Group "*" -

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

Associating groups with roles in namespaces
Associating groups with roles in namespaces


The group tree shows all existing groups:

  • Group "*": all non-logged-in users (anonymous) users belong to this group
  • Group "user" - : all logged-in users belong to this group. This is , the default group for all users on the wiki, every user belongs to this group by default
  • Subgroups of group "user" - : all groups that are defined on the wiki, eiter by default, by MediaWiki, or custom groups created by the wiki adminsan administrator. System groups, created by MediaWiki, can be hidden by unchecking the "Show system groups" checkbox above the tree.
  • Role matrix - table showing namespaces in columns and roles in rows

Role matrix[edit | edit source]


Viewing permissions contained in a role

The columns in the role matrix are:

  • Role information column - represented by an (info icon. ): Clicking on this icon opens a dialog listing the icon shows all the permissions contained in a particular role. The list shows permission names and short description. This list is exportable.
  • Role name
  • "Wiki" column - this column represents assignment Wiki: Assignment of a role to the entire wiki. By assigning the role in this column, a user group will receive gets permissions in the this role everywhere on the wiki (all namespaces).
  • Individual namespaces - Following columns represent : The following columns list every (applicable) namespace on the wiki.
    • Roles can be assigned to only certain namespace, eg. group "user" can be granted role "editor" only in namespace "Public", in order to be able to edit only pages in this namespacesindividual 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).
    • Same The same role can be granted to multiple groups for the same namespace.
    • Which namespace will appear Additional namespaces can be added in the matrix can be controlled by adding column to the grid, by clicking on the arrow in table header, then "Columns" and selecting desired columns.. Then the namespaces can be selected.

Role inheritance[edit | edit source]

By default, all roles granted to "the (*" ) group will be granted to "the user" group, and all roles granted to "the user" group will be granted to all of the groups that are a sub-group of the group "user"are granted to its subgroups. If a group inherits the role from an upper-level group field, this is indicated in the role matrix will be shown in greenwith a green background, but the checkbox won't be checked.

Technical

is empty.

Default roles[edit | edit source]

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.
Screenshot: bot permissions
  • 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.
  • admin: Grants access to all administrative special pages and to all typical administrative features.
  • maintenanceadmin: Similar to the admin role, but with extended admin rights for maintaining wiki integrity.
  • 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.
  • 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.
  • 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.
  • 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.
  • reader: Basic read access. Users can also edit their personal settings.

Important! The default roles and related permissions are different in the BlueSpice pro Cloud permission manager.


Technical info[edit | edit source]

Logging[edit | edit source]

Every change to the roles is logged in the MediaWiki log book, found under Special:Log under , in the Permission Manager log type . These logs are availble available only to wiki administrators (users in groups that have "admin" role grantedwith the role admin).

Backups

Configuration[edit | edit source]

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

See also[edit | edit source]

Reference page for this extension.

  • 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


Attachments

Discussions