Roles and Permissions

Roles and Permissions

A role is a named set of permission grants, optionally restricted to specific channels. Each user holds at most one role, and a user with no role is denied everything. Roles are created, edited, and assigned from the plugin's settings tab.

The Settings Tab

The plugin adds a Role-Based Access Control tab to the Settings view with two tables:

• Roles - every role with its ID, name, and description. Add, Edit, and Delete buttons sit beside the table; double-clicking a row also opens the editor.
• User-Role Assignments - every engine user with their assigned role, or (none) if they have no role. Assign Role and Remove Role buttons act on the selected user.

Changes on this tab commit to the server the moment you confirm each action. There is no staged Save: the tab's Save button does nothing, and a notice at the top of the panel says so. This is deliberate. Every mutation goes through its own confirmation dialog instead, and the delete, assign, and remove confirmations remind you the change takes effect immediately.

Deleting a role removes it outright. Users assigned to it lose all access, and the confirmation dialog spells that out before you commit.

The Role Editor

Add and Edit open the role editor: a name, a description, and two tabs, Permissions and Channel Restrictions (a choice between all channels or a specific-channel whitelist). The dialog's button is labeled Apply rather than Save, because confirming it commits the role via REST on the spot.

Permission groups

Each permission is a checkbox, organized into 14 functional groups. A checkbox only appears when the server's permission catalog actually contains that permission.

Group	Permissions
Channels	viewChannels, viewChannelGroups, manageChannels, clearStatistics, startStopChannels, deployUndeployChannels
Messages	viewMessages, removeMessages, removeResults, removeAllMessages, processMessages, reprocessMessages, reprocessResults, importMessages, exportMessagesServer
Dashboard	viewDashboard
Alerts	viewAlerts, manageAlerts
Code Templates	viewCodeTemplates, manageCodeTemplates
Global Scripts	viewGlobalScripts, editGlobalScripts
Tags	viewTags, manageTags
Events	viewEvents, removeEvents
Users	manageUsers
Extensions	manageExtensions
Server Settings	viewServerSettings, editServerSettings, backupServerConfiguration, restoreServerConfiguration, clearLifetimeStats, sendTestEmail
Configuration Map	viewConfigurationMap, editConfigurationMap
Database	editDatabaseDrivers, viewDatabaseTasks, manageDatabaseTasks
Resources	viewResources, editResources, reloadResources

Extension permissions

Permissions published by other installed plugins appear below the core groups. Since 1.1.2 each renders under a header named for its publishing plugin; anything the server cannot attribute lands under Other. Against a pre-1.1.2 server the grouping data isn't available, so all plugin permissions fall under Other. The grouping is cosmetic and has no effect on enforcement.

Presets

• Select All - checks every permission.
• Deselect All - clears every permission.
• Read-Only - checks exactly the view permissions: viewDashboard, viewChannels, viewChannelGroups, viewTags, viewMessages, viewAlerts, viewCodeTemplates, viewGlobalScripts, viewEvents, viewServerSettings, viewConfigurationMap, viewDatabaseTasks, viewResources. This is the minimum set for a functional read-only user: everything visible, nothing editable.

The manageExtensions warning

The manageExtensions checkbox carries a warning tooltip, and it earns it. A user who can manage extensions can disable the RBAC plugin itself, and on the next server restart the engine falls back to its default always-allow authorization controller. Every user then effectively becomes an admin. Treat manageExtensions as an admin-equivalent grant and give it only to fully trusted administrators. This mirrors stock OIE, where managing extensions already means installing arbitrary code on the server.

Safety nets on Apply

• Base-permissions warning - a usable login needs viewDashboard, viewChannels, viewChannelGroups, and viewTags. If the role is missing any of them, the editor warns that users with this role may not be able to use the UI and asks before applying. You can apply anyway; the warning exists because a role that passes login but renders a broken client is a common mistake.
• Orphaned grants are preserved - a granted permission that isn't in the current catalog (say, the plugin that published it is temporarily uninstalled) gets no checkbox, and it is kept as-is on save. An unrelated edit never silently revokes it. Reinstall the plugin and the checkbox comes back, already checked.

The Admin Role

The role seeded at install for the initial admin user behaves differently from the rest:

• Identified by a flag, not its name - the admin role carries an is_admin flag set at seed time. The name is cosmetic and can be changed.
• Holders bypass all permission checks - a user assigned to the admin role is authorized for everything, regardless of the permissions stored on the role. Multiple users can hold it.
• Cannot be deleted - refused in the client and enforced by the server.
• Locked down in the editor - only the description is editable. The name field, the permission checkboxes, the preset buttons, and the channel controls are all disabled, and Apply re-sends the stored permissions unchanged. Renaming the admin role is still possible through the REST API.
• No channel restrictions - the server rejects any attempt to restrict the admin role to specific channels.
• The admin floor - the server refuses to remove or reassign the last remaining admin user's role, so you cannot lock yourself out. Only live users count toward the floor: an assignment left behind by a user since deleted from the engine does not satisfy it.

Assigning a Role

Select a user, click Assign Role, and pick a role from the list. Before anything commits, the panel shows an impact preview: the user's current role, the new role, its channel scope, and the full sorted permission list. You confirm against exactly what the role grants, not just its name:

User:         bob
Current role: (none)
New role:     RO

Channel access: restricted to 2 channel(s):
  Alpha
  id2 (deleted)

Permissions (2):
  viewChannels
  viewDashboard

An unrestricted role shows Channel access: All channels. A channel the role still references but which no longer exists shows as its id with (deleted). A role with no permissions at all gets an explicit warning line, (none — the user could log in but perform no actions), so an empty role can't slip through looking harmless. The assignment takes effect immediately once you confirm.

Remove Role strips the selected user's assignment after a confirmation. With no role, the user is denied everything server-side.