Roles and permissions
A role answers two questions: what its holders may open (menus, queries, dashboards, the assistant) and which rows they see. Users receive roles; a user with several roles gets the sum of them.
Roles are edited in Liberty Next → Administer → Access → Roles. The role list is on the left; the selected role opens in a panel with two tabs: Access and Data scope.
This page is about the roles of Liberty Next itself. JD Edwards EnterpriseOne roles and their security are managed in Nomajde.
At a glance
The Access tab
Baseline
| Choice | Meaning |
|---|---|
| No access | Nothing, plus what you allow below. |
| Full access | Everything, minus what you deny below. The role card shows a Full access tag. |
The menu tree
The Menus block shows the sidebar of every application, one block per application (sales · 4 of 6 shown). Each folder and each entry has a three-state control:
| Control | Effect |
|---|---|
| Inherit (–) | The node takes the state of its folder, or the baseline. The row says inherits: allowed / denied / no access. |
| Allow (✓) | The node and everything under it are granted. |
| Deny (⊘) | The node and everything under it are refused, even if another rule would grant them. |
A folder cascades to its children; a child can override it. An entry shows, in grey, what it runs (sql:sales:orders_get, a dashboard…): allowing the entry grants both the menu entry and what it runs. The eye on each entry previews the result: green, the entry appears in the holder's sidebar; crossed out, it does not.
Two typical roles:
- Everything except the Security folder: Full access, then Deny on the Security folder.
- Only the Reports folder: No access, then Allow on the Reports folder.
Beyond the menus
Some rights are not tied to a menu entry. The Beyond the menus block adds them as green (allow) or red (deny) chips: pick Allow or Deny, the type, the item, then Add.
| Type | Grants |
|---|---|
| Connector (all queries) | Every query of a connector. |
| Query | One query — for a screen reached from a button or a link rather than from the menu. |
| API endpoint | One endpoint of an API connector. |
| Dashboard | One dashboard. |
| Data Explorer | One explorer model, or every model of an app — see Data Explorer. |
| nomaflow | Follow the jobs (nomaflow:view) — the Jobs, Schedule and Job Runs pages, the runs and their logs; Create and edit jobs (nomaflow:edit) — create, change, pause and resume jobs; it runs SQL and Python without row scope. See Nomaflow administration. |
| Job | One Nomaflow job, or Every job (job:*): its menu item and its page — files, parameters, run, cancel, logs of every run. See Run a job from an application's menu. |
| AI assistant | The assistant. |
| Pattern (expert) | A permission written by hand, such as sql:sales:report_*. |
Save writes the role; Cancel drops the changes. The role name cannot be changed after creation.
Data scope — which rows
The Data scope tab restricts the rows a role sees, on every screen, export, dashboard, report and assistant answer that reads a SQL connector. A role without any rule sees every row.
A rule
| Field | Choice |
|---|---|
| Dictionary item or Column name | What to restrict. A dictionary item (CO — Company) reaches every column that carries it, in every query; a column name restricts that column only. |
| Connector | Any connector, or one connector — the rule then says nothing about the others. |
| Fixed values or From the user's attribute | The allowed values, picked from the item's list when it has one; or a user attribute (company), so that one role serves every company — each user carries their own value (see Users). |
| Exclude these values instead | Turns the list into exclusions: SY not in 00. Empty values stay visible. |
| A query without this item | is unrestricted: a query that has no such column is not limited by this rule. returns nothing: such a query returns no row for this role (tag deny if absent). |
Each rule appears as one line: Company (CO) in 00001, 00050, SY not in 00, Company (CO) = user.company. Clicking a line loads it in the form; the bin removes it. Rules are saved with the role.
How rules combine
- Within a role, rules add up: company in 00001 and SY not in 00.
- Across a user's roles, the most open role wins: a user holding subsidiary and group sees what group sees.
- A role without rules removes every restriction for its holders.
- Superusers are never restricted.
Where it applies
- Reads: every query of a SQL connector is filtered on the server, whatever calls it — screens, exports, dashboards, reports, the assistant.
- Writes: creating, changing or deleting a row outside the scope is refused (403).
- Not filtered: API connectors and Nomaflow jobs, which run without a user.
Finding the column of an item
A query column carries a dictionary item when the screen says so, when it has the item's name, or — on a connector with a Dd Prefix (JD Edwards: 2) — when its name without the table prefix is the item: ABCO, MCCO and SDCO all carry CO. A join of two tables restricts both columns. On a pool that trims fixed-length text (JD Edwards), values are compared trimmed.
When a change takes effect
The scope is computed at sign-in and travels with the session. A change of role or of user attribute applies when the session is renewed — within the hour, or at once after signing out and in. The Profile window shows a user their attributes and their data scope in words.
Without the editor
The same rules can be set with liberty-admin set-scope and set-attributes (CLI), or in auth.toml:
[roles.subsidiary]
permissions = ["menu:sales:*", "sql:sales:*"]
scope = [
{ dd = "CO", source = "#USER.company#", mode = "deny" },
{ dd = "SY", values = ["00"], exclude = true },
]
How permissions are checked
Every permission is a colon-separated string — menu:sales:orders, sql:sales:orders_get, dashboard:sales_overview, ai:chat — and the editor writes them for you. For a request, Liberty Next takes all the permissions of all the user's roles, then:
- a superuser is always allowed;
- a matching deny refuses — a deny in one role wins over an allow in another;
- a matching allow grants;
- otherwise, refused.
* matches one segment, or everything when it ends the string (sql:sales:*).
Common pitfalls
| Situation | Explanation |
|---|---|
| A user still sees a menu after its role changed | The session carries the rights: sign out and in, or wait for the renewal (within the hour). |
| A deny meant for one role blocks another | Denies apply across all the user's roles. Prefer No access plus allows for narrow roles. |
| A query of the role returns nothing | A rule in returns nothing mode, and the query has no column carrying the item. Use is unrestricted or add the column. |
| A user with an attribute rule sees nothing | The user has no value for the attribute — see Users. |
| Roles cannot be deleted from the editor | Remove the role from its users; an unused role grants nothing. |