Overview
Object-level permissions (on data points, dashboards, etc.) control who can see and edit specific data. System permissions grant capabilities that are not attached to any one object — creating data sources, viewing the users page, running a backup, using a scripting engine.
Set your expectations first, because this is the part that surprises people: most of the Administration menu cannot be delegated at all. Admin home, Modules, System settings, System status, Import/Export and the SQL console are all restricted to the superadmin role in the menu definition itself, with no system permission in front of them. System permissions are a specific, enumerable set of capabilities — not a general switchboard for admin pages.
System Permissions vs Object Permissions
| Permission Type | What It Controls | Where It's Set |
|---|---|---|
| Object permission | Read, edit and set access to one specific data point, dashboard or watch list | On that object, in its own read/edit permission fields |
| System permission | A named capability that is not tied to one object — create a data source, view the users page, use the Nashorn engine | Access management → System permissions |
A user might have object-level read access to a data point but no system permission to create data sources. Both layers work together, and a few permissions deliberately straddle them: Data Point view permission (user.view.dataPoint) is a system permission that grants read on every data point, bypassing each point's own read permission.
What the Page Actually Lists
Every system permission is contributed by a module, and the page groups them the same way. Most groups are headed "<module name> module"; two are named in their own right, User permissions ("Manage access for creating and editing users") and Scripting engines ("Manage access to scripting engines and their features"). The label on each row is the permission's own description, which reads as a short sentence rather than a category name. The ones a typical deployment cares about:
| Row on the page | What it grants | Contributed by |
|---|---|---|
| Data source management (create/edit data sources) | Creating data sources, and with it the Data integration → Data sources page. Editing an existing data source is governed by that data source's own edit permission, not by this | Core |
| View users page | Reaching Access management → Users at all | User permissions |
| Create users | The Add user button. Editing an existing user is that user's own edit permission | User permissions |
| View events page | The Events page and the alarm counts. An operator who acknowledges alarms needs this, and every logged-in user holds it by default | Core |
| View any event | Reading every event regardless of its own read permission | Core |
| Create event handlers | Creating handlers. Note the Event Management → Event handlers page is still superadmin-only | Core |
| JSON configuration import / JSON configuration export | Configuration import and export as capabilities. The Import/Export pages remain superadmin-only | Core |
| Edit UI settings / Edit UI pages / Edit UI menus | The three Platform management editors — UI settings, Edit pages, Edit menu | UI |
| Configuration backup, Database backup, Restore database, Purge all events, Purge now using purge settings | One-off actions, each its own permission | Core |
| Send email to any email address | Addressing email to an arbitrary recipient | Core |
| Use the Nashorn JavaScript engine, Load scripts from the web, Write to the script log, and eleven more | Scripting is not one permission. Each engine and each risky binding is separate | Scripting engines |
What Is Not a System Permission
These are restricted to superadmin in the menu definition, so no amount of permission configuration will give another role access:
- Modules, including the upgrade and offline-upgrade pages
- System settings and every page beneath it — email, purge, password, database backup, UI, thread pools
- System status, Admin home, Auto login (local), Point value import
- SQL console, which is hidden from the menu entirely and reached through Utilities
- Import/Export, Publishers, Bulk data point edit, File stores, JSON store, Event handlers
- System permissions itself
In the core UI exactly six menu entries are gated by a system permission rather than by superadmin: Data sources, Users, UI settings, Edit pages, Edit menu, and the UI examples. Everything else you can delegate is a capability rather than a page.
Configuring System Permissions
- Navigate to Access management → System permissions
- Click a group header to expand it, or type in Filter permissions to search every group at once
- The grid has one column per role. If the role you want is not yet a column, click Add column and pick it — or click it in the Other roles with access cell on that row
- Tick the checkbox where the permission and the role meet
There is no Save button. Each row saves on its own the moment you tick it, and a progress indicator appears on that row. The superadmin column is always ticked and always disabled.
Two details worth knowing. Advanced mode, on the Add column drop-down, creates a column that requires a user to hold several roles at once rather than any one of them. And Hide column only removes a role from your view — it does not revoke anything.
The page itself is restricted to superadmin, so only a superadmin can change who holds what.
What Each Permission Starts As
When a permission has never been configured, Mango by Radix IoT falls back to that permission's own default. Most default to superadmin only, so a role you create holds none of them until you tick it in here. Some default to the built-in user role instead, which every logged-in account holds, so everyone who can log in has them from the start. The ones a deployment notices: View events page, Watchlist view permission, Watchlist create permission, Edit own user details (name/email etc), Edit own username, View Excel reports, Create Excel report template, Core filestore read permission (the default file store), Write to the script log and Access Mango services. To take one of these away from everybody, remove user from that row and tick the roles that should keep it.
An instance upgraded from Mango 3 carries whatever its old permission settings were converted to, so read the page rather than assuming these defaults.
Recommended Permission Assignments
Mango ships three roles and only three: superadmin, user (which every authenticated account holds) and anonymous. engineer, operator and viewer below are roles you create yourself on the Roles pane of the Users page; the columns are a starting point, not built-in.
| Permission | engineer | operator | viewer |
|---|---|---|---|
| Data source management (create/edit data sources) | ✓ | ||
| View events page | ✓ | ✓ | ✓ |
| View any event | ✓ | ||
| Create event handlers | ✓ | ||
| View users page | |||
| Create users | |||
| JSON configuration export | ✓ | ||
| JSON configuration import | |||
| Edit UI pages / Edit UI menus / Edit UI settings | ✓ | ||
| Configuration backup | ✓ | ||
| Database backup / Restore database | |||
| Purge all events / Purge now using purge settings | |||
| Scripting engines group (all fourteen) | ✓ |
Blank rows are the ones to leave with superadmin alone. View events page is ticked for all three because without it a user cannot open Events or see alarm counts. On a new install it is already granted to user, so those three ticks change nothing until you remove user from that row; then they are what keeps these roles' access.
Common Patterns
Engineer Self-Service
Tick Data source management for the engineer role. That is enough to create data sources and reach the Data sources page, and because creating a data point requires the edit permission on its parent data source, an engineer who owns the data sources can add points to them without any further system permission. System settings is not on the table — it cannot be delegated.
Locked-Down Operations
Operators need one system permission: View events page, which they already hold through user unless it has been removed. Everything else they do is object-level — viewing dashboards, setting points, and acknowledging alarms, which requires the edit permission on the event rather than any system permission. All configuration changes go through engineers or superadmins. For a genuinely locked-down instance, also remove user from the other rows that start with it (the watch-list, Excel report and own-account rows) and tick them only for the roles that need them.
Delegated Admin
In large organizations, create a site-admin role and tick View users page, Create users and Data source management. Module and system-settings access is not something you have to withhold — it was never available to delegate. Be aware of what this role still cannot do: it cannot edit an existing user unless that user's own edit permission includes the role, and it cannot reach the System permissions page to widen its own access.
Troubleshooting
| Issue | Cause | Fix |
|---|---|---|
| User can't see the Administration menu | Expected. Every page under Administration requires superadmin, so a non-superadmin sees nothing there no matter what you tick | Nothing to fix. If they need one of those pages, they need the superadmin role |
| Engineer can't create data sources | Data source management does not include their role | Tick their column on that row |
| Engineer can create a data source but not add points to someone else's | Point creation needs the parent data source's edit permission, which is object-level | Add the role to that data source's edit permission — not to a system permission |
| User can open the Users page but every edit fails | View users page grants the page only. There is no "edit users" system permission | Add the role to the edit permission on each user, or grant Create users if they only need to add accounts |
| Operator sees no alarms | View events page no longer includes user or their role | Tick it for their role. Acknowledging additionally needs edit permission on the event |
| A permission reverted to superadmin only | The role was deleted. Deleting a role strips it from every permission that referenced it | Recreate the role and re-tick it |
Summary
System permissions grant named capabilities, not admin pages. Configure them at Access management → System permissions, where each row saves as you tick it. Most rows start superadmin-only; a few, including View events page, start granted to every logged-in user. Assign them to roles rather than to individual users, remember that Administration is superadmin territory no matter what you tick, and expect the useful delegation — data source management, the users page, the events page, the UI editors — to come from a short and specific list.