Overview
Mango by Radix IoT has two kinds of permission. System permissions are named capabilities, such as View events page or creating data sources, set on Access management → System permissions. Every page under Administration requires superadmin, so no role can be given the administration of the instance. Object permissions are fields on each object (a data point, a page, a watch list, a report template) that decide which roles can see, change or use that one object. This lesson is about the second kind, which is how one Mango instance serves several sites or customers without showing each one the others' data.
Prerequisites
- Superadmin access, or edit permission on the objects you are changing
- At least one custom role created on the Roles card at Access management → Users
- Basic understanding of Mango roles (see Understanding Role-Based Access Control in Mango)
How a Permission Is Checked
Every permission field shows the same table: Superadmins (always ticked), Users, Anonymous, and Other roles with access, where + adds a column for a role you created. A user passes when:
- they are a superadmin, or hold superadmin through inheritance, or
- they hold every role of at least one entry, counting roles they inherit. With the ordinary one-role-per-column table, that simply means holding any one ticked role; Advanced mode lets one entry require two roles together
An empty permission is superadmin-only. Users is the user role, which every logged-in account holds, so ticking it opens the object to everyone who can sign in; Anonymous opens it to visitors who have not.
Where Each Object's Permissions Are
| Object | Permissions | Where |
|---|---|---|
| Data point | View point & value, Edit point, Set point value | The data source's Data points tab → the point → its Data point tab |
| Data source | View data source, Edit data source | The data source's own tab |
| Page (dashboard) | View page, Edit page | Platform management → Edit pages, Edit page name and permissions (or Create new page) |
| Watch list | View watch list, Edit watch list | Analytics → Watch list builder, Watch list settings |
| Menu item | View menu item, or Link to system permission | Platform management → Edit menu |
| Excel report template | Read generated report, Edit report template (running one needs Edit report template); the data is read as the template's Report execution roles | Analytics → Excel reports |
| Event handler | View event handler, Edit event handler | The Event handlers page, which itself requires superadmin |
Setting Permissions on Data Points
- Open the data source and its Data points tab, then open the point
- On its Data point tab, under Permissions:
- View point & value: who can see the point and its values (and its alarms)
- Edit point: who can change its configuration
- Set point value: who can write or command a value on a settable point
- Tick the roles, or add a role column with +, and save
Many points at once: Data integration → Bulk data point edit (superadmin only). Use Select tags to add tag columns, filter on them, tick the matching points, and choose Edit selected data points. Tags only help you find the points: they carry no permissions themselves.
Setting Permissions on Pages
- Go to Platform management → Edit pages and choose the page
- Open Edit page name and permissions
- Set View page (who can open it) and Edit page (who can change it), and save
Setting Permissions on Watch Lists
- Open the watch list in Analytics → Watch list builder
- On Watch list settings, set View watch list and Edit watch list, and save
Warning
A watch list never shows a point the viewer cannot read. Mango filters its points by each viewer’s View point & value, so a watch list opened to a role still looks empty to that role until the points are opened to it too.
The Permission Chain Behind a Dashboard
For a user to see live data on a page reached from the menu, every link must include one of their roles:
- Menu item: View menu item (or a linked system permission), or the entry is not in their menu
- Page: View page
- Watch list: View watch list, but only if the page takes its points from a watch list
- Data points: View point & value on every point the page shows
A break at the last link does not raise an error: the widget is simply blank. That is why the points and the watch list are the layers most often missed.
Note
Alarms follow the point. A data point’s events are visible to whoever has that point’s View point & value, and the Events page itself needs the View events page system permission (every logged-in user holds it on a new install). Platform Manager’s Site overview and Device details likewise show only the points the viewer can read.
Common Permission Patterns
Pattern 1: One Page, Site-Specific Data
Open one page to all operators, and give each site's points (and any watch list the page uses) only to that site's role. Widgets that take their points from a watch list then show each user only their own site's points; a widget bound to one specific point shows blank to anyone who cannot read it. One layout, no copies per site.
Pattern 2: Read-Only Operators, Commanding Engineers
Operators get View page and View point & value. Engineers also get Set point value for setpoints and commands, and Edit page if they maintain the layout.
Pattern 3: Multi-Tenant Customer Segregation
Each customer has their own role, and their pages, watch lists and points are opened to that role only. Customer A cannot see Customer B's data on the same instance. A customer's role can own and edit its objects, but it can never administer the instance itself.
Testing Permissions with Switch to User
A superadmin can open a user's More options menu at Access management → Users and choose Switch to user to act as that account and verify they see exactly what they should, and nothing more. Always test after making permission changes.
Tip
After every permission change: (1) Switch to user as an account holding the target role, (2) check the menu entry is there and the page opens, (3) check every widget shows data, (4) check the Events page shows the alarms you expect, and (5) switch back to your own account. This catches gaps before users report them.
Role Inheritance
A role inherits the roles listed on it. If role-B inherits role-A, anyone holding role-B passes every permission that names role-A; the reverse is not true. Use it carefully, because an inherited role can quietly widen access.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| User can open the page but widgets are blank | The points, or the watch list feeding them, are not open to the user's role | Add the role to the points' View point & value, and to the watch list's View watch list if the page uses one |
| Page works from a link but is missing from the menu | The menu item's View menu item leaves the role out | Edit the item at Platform management → Edit menu |
| User sees too much data | Users ticked on a permission (everyone logged in), or role inheritance | Untick Users; audit role memberships and inheritance |
| User can view but not command a setpoint | Role in View point & value but not Set point value | Add the role to the point's Set point value |
| User cannot see a point's alarms | No View point & value on that point, or no View events page permission | Grant the point permission; check System permissions |
Summary
Object permissions decide who sees, changes and commands each item in Mango. For a dashboard, check the whole chain: menu item, page, watch list (if the page uses one) and every data point. Use Bulk data point edit to set points at scale, test with Switch to user, and be careful with the Users column and role inheritance.