Roles

This screen manages NomaUBL's role-based access control. Each role bundles four kinds of grant: a list of pages the role can reach, a list of companies the role is scoped to, a list of features (settings access, read-only mode), and the members assigned to the role.

Roles are application-wide and source-agnostic — they apply equally whether NomaUBL is plugged into JD Edwards, SAP, NetSuite or a custom ERP. Default roles (admin, viewer) are seeded by the Initialize Database action in Database Connectors → NomaUBL.

Refreshed in 2026.05.5

The roles model went from CSV columns to row-based grants:

• F564254 permissions table — each grant is a row keyed by type (page / company / feature). The four CSV columns RLPAGES / RLCOMPANIES / RLSETTINGS / RLREADONLY on F564251 are gone. Adding a new permission dimension is now an INSERT, not a DDL change.
• Editor redesign — card list with copy and delete actions per role, expanded edit panel with per-feature checkbox + helper text, companies as an add-row table (no more comma-separated text), Allowed Pages with friendly labels (i18n nav.* keys reused from the sidebar) plus the page id beside it in muted monospace.
• Idempotent bootstrap — dropping F564254 and re-running Initialize Database re-seeds the default admin and viewer grants without touching existing role rows. The log reports the count of newly-inserted grants.
• Sessions table — F564252 columns aligned to JDE conventions (SSLSID UUID token, SSUSER, SSSTDTIM start time, SSETDTIM end time). F564251 keeps identity only.

---

Opening the editor

• Sidebar → Configuration → Security → Roles.
• The page opens with every existing role as a card. Click any card to expand the edit panel below the list. Use + New Role at the top right to start from scratch — the same edit panel opens with the Name field unlocked.

---

At a glance

---

Roles list

The top of the page lists every existing role as a card.

Element	Description
Name	Internal identifier of the role (e.g. admin, operator, viewer). Used to bind users to the role from the Users editor.
Description	Free-text human-readable summary.
Member count	Number of users currently assigned to the role.
Badge	Admin when the role has the Settings access feature, User otherwise. Quick read of the role's reach.
⎘ Copy	Duplicates the role: pre-fills the edit panel with all grants of the source role; the Name field is empty for the user to choose a new one; the description gets (copy) appended.
🗑 Delete	Removes the role after confirmation. Users assigned to it lose every permission until reassigned.

Click any card to open the Edit panel below the list. Use + New Role at the top right to create a new role from scratch.

---

Edit panel — Permissions tab

Identity

Field	Description
Name	(visible only when creating) Internal identifier of the role. Must be unique.
Description	Human-readable summary shown in the role list.

Features

A short list of binary feature flags. Each row carries a checkbox plus a one-line helper that explains what the flag does.

Feature	Helper text	Effect
Settings access	Can open the Settings page (template / connector editing).	Opens the entire Configuration menu. The role is then displayed with the Admin badge in the list.
Read-only mode	No edit / delete / resend actions, even on permitted pages.	Members can browse the application but every write action is disabled — useful for auditors / observers.

Companies

An add-row table of company codes (KCO) the role is scoped to. Each row carries a free-form input and a × button to remove it; + Add company at the bottom appends a new row.

• Empty list = all companies. This is the typical default — leaving the table empty grants the role access to every company in the database.
• Adding even one row restricts the role to just the listed companies.
• The placeholder hint reads KCO code (e.g. 00001) and the input uses a monospace font to make typos easier to spot.

Allowed Pages

A grouped checklist mirroring the application's left-hand navigation. Each page checkbox shows the friendly label (the same i18n nav.* key the Sidebar uses) plus the page id in muted monospace beside it — so the row stays informative when localised yet still searchable by id.

Group	Pages
Navigation	dashboard, invoices, ereporting, edirectory, notifications, integrationerrors, processinglog
Processing	fetchinput, import, retrievestatuses
Operations	process, extractandprocess, processapi
UBL	validate, xsleditor, xmlviewer, ubldefaults
Extract	extractbip (JD Edwards-specific), extract, extractftp
Documentation	releasenotes, statusreference, reasoncodes, ublreference, xref
Management	documents, pdftemplates, actions, notificationrules, fileversions

Helpers:

• All / None buttons above the groups — instantly grant or revoke every page.
• Per-group checkbox + check all / uncheck all toggle — flip an entire group in one click.
• A group's checkbox shows an indeterminate state when only some of its pages are selected.
• Empty list = all pages allowed. Same convention as the Companies field: an unfiltered role sees everything.

Save / Cancel

• Create (when creating) / Save (when editing) persists the role and refreshes the list.
• Cancel discards changes and closes the panel.
• Inline status messages appear below the panel (Role created, Role updated, Role deleted, error messages).

---

Edit panel — Members tab

Available only when editing an existing role (hidden during creation).

Lists every user currently bound to the role:

Column	Description
Username	The user's login.
Full name	The user's display name (or – when not set).
Status	Active (green) or Inactive (red).

This view is read-only — to add or remove a user from a role, edit the user from Configuration → Security → Users.

---

How grants are stored

In 2026.05.5 the four CSV columns on F564251 were replaced by a dedicated row-based grants table.

F564254
  PMROLE       — role name (FK to F564251.RLNAME)
  PMCRAPPID    — grant type: 'page' / 'company' / 'feature'
  PMCRAPPVAL   — grant value: a page id, a KCO code, or a feature flag
  PMENABL      — '1' enabled / '0' disabled (used during dialect-specific bootstrapping)

Saving the role from the editor writes one row per page, one row per company, and one row per feature. Adding a future permission dimension (e.g. per-document-type access) becomes an INSERT in this same table — no DDL change required.

The bootstrap is idempotent: dropping F564254 and re-running Initialize Database re-seeds the default admin and viewer grants without touching role rows. The init log reports the count of newly-inserted grants for visibility.

---

Delete a role

Clicking the 🗑 icon on a role card opens a confirmation modal:

Delete role "X"? Users assigned to this role will lose their permissions.

Confirming removes the role and every grant row in F564254 keyed by it. Users previously bound to the role keep their account but lose every permission until they are reassigned to another role.

---

Tips & best practices

• Create one role per profile, not per individual. operator, auditor, admin are simpler to maintain than per-user roles.
• Grant Settings access sparingly. It opens the entire Configuration menu — limit it to a small admin group.
• Read-only mode is ideal for compliance / audit accounts. Combined with Settings access off, it provides a non-destructive walk-through of the system.
• Use the Companies table to enforce multi-tenant isolation. Leaving the table empty defeats company-level filtering for the role.
• Use Copy when forking a role. Starting from an existing role with one or two grants flipped is much faster than rebuilding the checklist from scratch — and the result is closer to the source role's intent.
• Re-run Initialize Database (Database Connectors → NomaUBL) if the default admin or viewer grants are missing — it re-seeds the rows without touching custom roles.
• Delete a role only after re-binding its members. Once deleted, members lose access to everything until reassigned. The Members tab is the fastest way to check who would be affected.