Permissions
Permissions control access to functions and content in OpenVLE.
You determine which users or roles are allowed to perform specific actions such as Read, Create, Edit, or Delete.
In this section, you can manage existing permissions.
Where can I find this section?
Via main menu: Access Control -> Permissions
Alternatively accessible via: Linked via User or Role views
Features at a Glance
- View and manage existing permissions
- Filter and search by permission name or assigned roles
- Review which roles or users have a specific permission
Key Fields at a Glance
| Field name | Description |
|---|---|
Key (Slug) | Short name of the permission. Used internally within OpenVLE. |
Name | The name of the permission, e.g., "Read activities" or "Create manufacturers". Displayed in lists and associations. |
Adding Object Permissions for a User
For various object models, direct object permissions can be granted.
This means the user receives a permission only for a specific object — not for all objects of the same type.
-
Search for and open the desired object.
-
Switch to the Permissions tab.
If this tab is not available, you either lack the required permissions to create object permissions, or the corresponding object model does not support object permissions. -
Click the green plus button.
-
In the input form, you can search for the desired user and select the appropriate permission.
The following permissions are available by default:- Read
- Read & Edit
- Full Access
For virtual machines (VMs), the additional permission Read & VM Control is available,
which also allows the user to perform actions such as Start, Stop, or Reboot on the VM. -
Save the permission.
Removing Object Permissions from a User
- Open the relevant object.
- Switch to the Permissions tab.
- In the list of existing permissions, click Remove on the desired row, or open the context menu and select Delete.
- Confirm the action in the displayed dialog.
Removing an object permission takes effect immediately — the user instantly loses access to the respective object.
Example or Use Case
An administrator wants to specify that only instructors may create new
environments. To do this, they create a new Environment Manager role and
assign it the courses_create permission. This way, only members
of this role can create new environments, while other users cannot.
Notes / Special Considerations
- Permissions follow the CRUD principle (Create, Read, Update, Delete).
- Permissions can be assigned both globally and object-specific (scoped).
- Changes to a permission take effect immediately for all roles and users that use it.
- New permissions should only be created by administrators, as they directly affect system access.
- Via the Users and Roles tabs, you can see where the permission is assigned.
Relationships to Other Objects
Many objects in OpenVLE are related to other elements within the system. The following overview shows which relationships exist and whether they trigger certain automations.
| Object | Description | Automatic behavior |
|---|---|---|
| Roles | A permission can be assigned to any number of roles. | No automations. |
| Users | A permission can be assigned to any number of users. | No automations. |
Required Permissions
The permissions required for actions can be assigned via roles or individually. If you lack certain rights, the corresponding functions in the user interface are hidden or disabled.
| Action | Required permission | Path | Additional information |
|---|---|---|---|
| View permissions | permissions_read | / | |
| Create permissions | permissions_create | / | Deprecated |
| Edit permissions | permissions_update | / | Deprecated |
| Delete permissions | permissions_delete | / | Deprecated |
| View roles | roles_read | / |