How Can We Help?
A right (permission) controls one capability — confirm an order, view price, edit a user,
and so on. This chapter explains how rights are organised and how they are assigned.
What, where, who, when, why
| What | The permission model behind the user screens: individual rights (one capability each) and groups — reusable bundles of rights applied to a user with one tick. |
| Where | Groups are maintained on Administration and Setup → Users Profile Management; individual rights are granted from the tree inside Users Management. |
| Who | Administrators. Whoever owns the role definitions should own the groups; day-to-day user creation can then be delegated safely. |
| When | Define groups once, when the system is set up or a new role appears (e.g. “Purchasing”); then keep granting by group and reach for individual rights only as exceptions. |
| Why it matters | Groups turn permission management from per-user archaeology into one consistent role: change the group, and every member’s effective rights change on their next login. Enforcement is server-side — a hidden action (see action exclusions) is still enforced if granted. |
The permission model
Permissions are organised as a tree and granted per user:
→ Action one capability inside the module (Confirm Order, View Price, …)
→ User right the action granted to a specific user ← the effective grant
| Layer | What it is |
|---|---|
Module (system_module) |
A functional area — the top level of the permission tree. |
Action (system_module_action) |
One capability within a module. Actions have an active flag (see the gotcha below). |
User right (user_rights) |
The actual grant. A row here means “this user has this action”. This is what the system checks at runtime. |
Groups — reusable rights templates
A group is a named bundle of actions — a template. Groups are created and edited on their
own screen: from the main menu, Administration and Setup → Users Profile Management
(that is the name the groups screen carries in the menu). When you then tick a group on a user in
Users Management, the group’s actions are copied into that user’s rights. Groups make
it easy to give many users the same baseline, but note:
- Ticking a group copies its actions onto the user; the user’s effective permissions are
still their ownuser_rightsrows. - Actions that are hidden for the user’s partner type are not copied in through a group
(see Permission visibility).
The system also has system roles, but in the current flow they are effectively fixed and are
not how live permissions are decided. Think in terms of user rights (plus group
templates) — that is what actually gates the app.
How a permission is named
Internally each action has a numeric id, but those numbers are not a stable public
contract — the same number can mean different things in different places, and they have drifted
over time. Every capability is exposed at runtime under a named flag (for example
Confirm Order, View Price, View Commission, Create/Edit User).
When documenting or discussing a permission, use its capability name (what the checkbox
says), never the raw action id. The numbers are an internal detail and are not guaranteed to be
consistent.
Two behaviours worth knowing
A user with Is Admin gets every permission regardless of their rights list. If someone “can
do everything” unexpectedly, check whether they are an admin.
An action whose
active flag is off is granted to all non-admin usersautomatically — it is treated as “not gated”. So a capability that “just works” without an explicit
grant may simply be an inactive (ungated) action, not a bug.