Skip to main content

Permissions and scope

What an operator can do comes from two things: which actions they are allowed (permissions) and over which part of the hierarchy (scope).

Permissions: resource + action

Permissions are flat: four actions per resource, and none implies another.

ActionCovers
ViewLists, details and reports.
CreateCreating the resource.
EditModifying, activating/deactivating and managing sub-resources.
DeleteCascading deletion.

Grantable resources: Clients, Accounts, Operations, Devices, Inventory (device_inventory), Products, Consumer users, Codes, Profiles, Reports, Operators, Roles, Settings, API keys, Audit.

Flat, but View is the front door

Nothing implies anything: Edit does not grant View. In practice, without View you cannot open the list or the detail — and the edit buttons live inside them: a role with Edit but no View can do nothing through the interface. The useful rule: always tick View, then add what else is needed.

Two resources stand on their own:

  • Inventory (device_inventory) is separate from Devices: View inventory shows the Inventory tab, Edit inventory allows touching slots and the planogram. Seeing the device itself depends on View devices.
  • Codes is separate from Consumer users: codes are operation-level, so an operation-level operator can manage codes without being able to create or edit the user, which is account-level.

Resources reserved to INSSA

Controllers, device registration/removal (device_provisioning), server errors and lambda errors are reserved resources: they cannot be granted to any client role and do not appear in the app. That is why registering devices and controllers is a support request to INSSA.

Scope: where they apply

Every operator lives at a level: global, client, account or operation. Their permissions only apply to that node and everything below it.

ScopeSees
GlobalEverything (INSSA internal use).
ClientIts accounts, operations, devices, users…
AccountIts account and its operations.
OperationOnly its operation.

Outside scope, the answer is Your scope does not allow this action on the resource.

Role + extra permissions

The role is the template: it sets the operator's floor of permissions. When creating or editing them you may customise their permissions, and that list adds on top of the role.

SourceHow the editor shows it
From the roleTicked and locked, labelled Granted by the role. Unticking does nothing.
ExtraWhat you tick on top. It is the only thing stored as a customisation.

The effective permission is the union of both. To remove something from an operator you change their role: that is where the template lives.

Two limits the app always enforces:

  • No privilege escalation: you may only grant permissions you hold (the editor offers only yours).
  • No hierarchy jump: you only create operators at your level or below.

Your own node: edit yes, retire no

The level you belong to (your account, if that is your scope) is visible and editable with the matching Edit permission: legal name, contact, tags.

What you cannot do is deactivate or delete it: deletion cascades over the operators of that scope, yours included, and there is no restore. The app hides those two buttons and the server rejects them anyway. Nor can you touch a level above yours.

Creating: the level matters too, not just the permission

Creating a hierarchy entity requires standing above it. With the Create permission but at the wrong level, the app does not show the button and will not open the /new URL:

To createWho can
AccountGlobal and client. An account-level operator sees one account —its own— so it does not create accounts.
OperationGlobal, client and account. An operation-level operator only sees its own.
ProfileGlobal, client and account. Every profile belongs to the account; where it works is defined by its authorised devices.
Product, consumer user, codeAny level, within its scope.
OperatorAny level, at its own level or below.
Device, controller, clientINSSA only.

What the app hides and what it does not

The interface hides what you cannot use, but the definitive filter is the server.

Hidden or blocked by permission:

ElementPermission
Menu section (Accounts, Operations, Devices, Products, Profiles, Users, Audit) and its URLView on the resource
Dashboard and Movements (Deliveries, failed, Top-ups, Available credit, EAS, Returns)View reports + the screen's business line
Operators / Roles / Developer in the avatar menuView operators / View roles / View API keys
New buttons and their /new URLsCreate on the resource + the right level
Edit, activate/deactivate, moveEdit on the resource
DeleteDelete on the resource
Inventory tab and pageView inventory
Editing slots, planogram, fill/emptyEdit inventory
Add / edit / delete code, fingerprintsCreate / Edit / Delete codes
Bulk actionsEdit consumer users (per-row detail is validated by the server)
Users Export to ExcelView consumer users
Edit operatorEdit operators
Edit / delete roleEdit roles / Delete roles (system roles are never editable)
Create / revoke API keyCreate API keys / Delete API keys

Not permission-dependent (any authenticated operator): My profile, its preferences, password change, the notifications bell and the public QR receipt.

The server has the last word

Hiding a button is convenience, not security: every action is re-validated on the server against your permission, your scope and your business line. Land on a URL that is not yours and the app returns you to your home screen.

Business lines: which screens you get

Your operator inherits the business lines of its origin, and that decides which movement screens exist for you. The reports permission is a single one (View reports) for both lines, so the line is what separates them:

You handleYou see
Vending onlyDashboard, Deliveries, Failed deliveries, Top-ups, Available credit
EAS onlyEAS deliveries, Failed EAS deliveries, Returns
BothBoth groups in full

The Dashboard covers vending sales: an EAS-only operator does not see it, and their home screen after signing in is EAS deliveries.

The line also limits selector options: the Business line filter in lists, the line when creating an account, operation, product or profile, and the rows of the profile block when creating or editing a code (a vending-only operator does not see the EAS profile row).

Checklist when a button is missing

  1. My profile › Permissions: do you hold that action on that resource? And View?
  2. Is the resource inside your scope?
  3. Is it a hierarchy node — namely your node? Then you cannot deactivate or delete it.
  4. Is the resource's business line one of yours?