Permission System - OpenSlides/OpenSlides GitHub Wiki

This is a top-down view on the permission system. It is mainly split into three parts:

1. Permissions in the Organization level. In the organization management level only the field user/organization_management_level (see models.yml) is evaluated and there is no anonymous user. So this level is only accessible by registered and logged in users. Access is mostly determinated by assignment to objects, so a user can only see committees where he is a member. The organization_management_level is going to be null for most users. Just a handful of users will have a management level assigned.
2. Committee management is defined in user/committee_management_ids. Users with the OML at least can_manage_organization are automatically committee managers in all committees.
3. Permissions inside a meeting: Inside a meeting it must always be ensured, that the user can access the meeting (see Users#user-association-to-meetings). Inside the meeting permissions are controlled with groups. Each group has a list of permission strings. There are also two special groups: the default- and the admin-group.

The field user/organization_management_level can hold one of the following three values:

• superadmin
• can_manage_organization
• can_manage_users

These are hierarchical: superadmin includes can_manage_organization which includes can_manage_users.

A user with superadmin can do everything: He is allowed to see non-personal models (e.g. not personal notes or password hashes of other users), but can enter every committee and meeting and is transitively manager of each committee and admin of each meeting.

A user with can_manage_organization is indirectly a committee manager for every committee. The user can create, edit and delete committees and administrating resources and the motion forwarding structure. The user is only indirectly a committee manager, because the user can not create, update or delete any meetings within a committee.

A user with can_manage_users can see all committees and meetings (needed for assigning users to committees and managing meeting/guest_user_ids). Seeing these models does not include accessing committees and meetings (i.e. open a meeting in the browser). The user can create, update and delete normal users including merging users together, setting users to active or not (is_active) and modify basic fields. The user can assign users to committees as members or managers as well as users to meetings as guests. Rationale: The user manager is the instance to control the access of users to committees/meetings. Knowledge about the meetings is needed, e.g. for assigning guests.

The management status for each user and committee is given by the field user/committee_management_ids. Basic committee members (users without management rights in a specific committee) can see and access the associated meetings and basic properties of the committee.

Committee managers can do everything a basic member can do as well as see all meetings of the committee. A manager can create, delete, update meetings, set a meeting as the template, import meetings, export meetings and assign members to meetings.

Managers do not have implicit admin permissions due to the fact they are managers. They can be admins, but the committee manager is not transitive into the meeting.

Committee managers will be added as members of the corresponding committee, when they are assigned as managers. Afterwards, the permission to manage a committee can be removed from a committee manager. If this permission is removed, a committee manager will still stay as member of their corresponding committee. To remove committee managers completely from a committee, they have to be removed as members of the corresponding committee.

A user must be associated to the meeting to access it. Users with the OML superadmin can always access the meeting and have all permissions.

If the user is in the admin group (meeting/admin_group_id), he has all permissions.

Groups have a list of permissions (group/permissions, see models.yml). A users list of permission strings is the union of all his groups permissions strings.

Guests and anonymous users have the permissions of the default group (meeting/default_group_id). If a guest also has groups assigned, the permissions are taken from those groups and not the default one.

Most actions rely on a single permission. E.g. you need projector.can_manage to execute any projector action.

Permissions strings are hierarchical, see permission.yml. If a user has a permission string, he indirectly also have all nested permission strings.

Some permissions are bound to access groups. E.g. a user can write comments for comment sections, if the user is in at least one groups of motion_comment_section/write_group_ids. If the user is in the admin group, he is always included in these access groups, so an admin can always access the models.

Most actions are simple to described by the one permission needed. But there are more complex to check actions. The permissions are documented there.

If anonymous users are allowed (meeting/enable_anonymous), a anonymous user gets the id 0. He implicitly is in the default group (meeting/default_group_id). It must be ensured, that this id never gets into the database, so all actions that interact with the request user are forbidden for anonymous users.