Permission System
This is a top-down view on the permission system. It is mainly split into three parts:
- Permissions in the Organization level. In the organization management level only the field
user/organization_management_level
(seemodels.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. Theorganization_management_level
is going to benull
for most users. Just a handful of users will have a management level assigned. - Committee management is defined in
user/committee_management_ids
. Users with the OML at leastcan_manage_organization
are automatically committee managers in all committees. - 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.
- DE:Konzept OpenSlides 4
- Update Workflow
- Architecture
- Introduction to functionality
- Restrictions
- Buildsystem
- Development organization
- Services
- Technical details
- Potential Optimizations
- Best practices for developers