Operator guideENstaffformpermissions

Staff / Form

Combined create and edit workflow for one backoffice administrator account, including role, group, parent-admin, and permission matrix rules.

Reader view

Clean portal guidance

This page keeps the operator explanation, field and action descriptions, and screenshots visible without exposing repo paths, raw sidecars, or editorial-only implementation details.

Narrative content

Page body

What this form does

Use this form family to create a new admin account or update an existing one. The surface covers identity fields, role and group assignment, parent-admin logic for support users, and the stored permission matrix, but create and edit do not behave identically.

Create vs edit

Create

  • The create flow is used for new CRM administrator accounts.
  • Password is part of the initial payload.
  • Only Manager and Support are offered as visible role options.
  • Permission cards appear only after the role choice is made, and support mode also requires a selected parent admin.

Edit

  • The edit flow first loads the existing admin detail payload.
  • Password is optional on update and is only replaced when changed.
  • The FE edit surface keeps role read-only and limits some field edits based on the current role rules.
  • When the current operator edits their own account, the permission matrix is hidden.

Permission behavior

  • Permission checkboxes are not free-form. The FE requires the read permission R before non-read options can be enabled in the same category.
  • Create-mode support-user flows seed permissions from the selected parent-admin detail payload.
  • Create-mode manager flows seed permissions from the current operator detail payload.
  • Edit mode renders permission categories from the current operator permission map, not from a separate role template registry.

What can confuse operators

  • A role name alone does not fully describe access. The permission matrix is the detailed source of truth.
  • Group and parent-admin behavior changes with the selected role.
  • Editing your own record can be more restricted than editing another admin account.
  • The current forms do not expose a dedicated Cancel or back action; the only form-level action is Submit.
  • The current create implementation for Support attempts one support-scoped create and then falls through to a second create call with adminId: null.
Calculation notes

Calculations

calculation

Create versus edit shell

Verification
verified_backend
Logic
Create uses `CreateStaffForm`; edit uses `EditStaffForm`., Both forms expose only one visible form-level action, `Submit`., Create sends `POST /api/admin/create-admin-user`., Edit sends `PUT /api/admin/update-admin-user`.
calculation

Permission-source gating

Verification
verified_fe_only
Logic
Create mode shows permission cards only after a permission source exists., For `Manager`, the source is the current operator detail payload from `useAdminDetails()`., For `Support`, the source is the selected parent-admin detail payload loaded through `useAdminDetailsById`., `Toggle all` clears or repopulates the full permission matrix from that active source.
calculation

Support create double-submit

Verification
verified_fe_only
Logic
In create mode, choosing role `Support` and submitting triggers one `createStaff` call with the selected `adminId`., This is a current FE implementation caveat, not an intended operator flow.
calculation

Edit restrictions and self-edit lock

Verification
verified_fe_only
Logic
Edit mode keeps `Role` disabled., `Group` is disabled unless the edited staff role is `Manager`., For support users, `Parent Admin` is shown as a disabled display-only select., If the current operator edits their own record, the permission matrix is hidden entirely.
calculation

Password transport and change check

Verification
verified_backend
Logic
FE base64-encodes the entered password before create or update., Backend create encrypts and stores the provided value., Backend update only rewrites the stored password when the incoming value is non-empty and differs from the current password.
Field dictionary

Fields

field

Email

Login email and main staff identifier. Must stay unique.

Group
identity
Data Type
string
field

Password

Initial password on create, optional password replacement on edit.

Group
identity
Data Type
password
Caveats
FE base64-encodes the entered value before sending it to backend create or update., The backend only replaces the stored password when the value actually changes during update.
field

First Name

First name shown on the view screen and staff list.

Group
identity
Data Type
string
field

Last Name

Last name shown on the view screen and staff list.

Group
identity
Data Type
string
field

Username

Backoffice username stored on the staff record and checked for uniqueness.

Group
identity
Data Type
string
Caveats
0: Create Validation Is Stricter Than Edit Validation And Stricter Than The Backend Service: create accepts only letters and requires at least 8 characters.
field

Role

Primary access tier for the admin account.

Group
access
Data Type
enum
Caveats
Create exposes only `Manager` and `Support`., The FE edit form keeps role read-only after creation.
field

Group

Operator grouping used to segment admin accounts.

Group
access
Data Type
string
Caveats
Group editing is restricted by the current role path in FE.
field

Parent Admin

Parent-admin link used on support-user flows.

Group
access
Data Type
relation
Caveats
Create mode shows this selector only when role is `Support`., Edit mode shows it as a disabled display-only field for support users.
field

Permissions

Stored category-by-category permission matrix for the admin user.

Group
permissions
Data Type
permission-matrix
Caveats
The FE requires read permission `R` before non-read permissions can be enabled in the same category., Create mode renders the matrix only after the role path has a permission source., Edit mode hides the matrix when the current operator edits their own account.
Operational notes

Notes

item

CreateSuperadminUser enforces role hierarchy and forbids creating the SUPERADMIN role directly.

item

UpdateSuperadminUser validates unique email and username before persisting changes.

item

The create form hardcodes visible role choices to `Manager` and `Support`; it does not use the backend roles endpoint.

item

Notes 4

The Edit Form Is Stricter Than Create
role stays read-only in FE, password replacement is optional, and group editing is disabled unless the edited staff role is `Manager`.
item

Notes 5

The Current Create Submit Handler For `Support` First Posts With The Selected Parent Admin Id And Then Falls Through To A Second Create Call With `AdminId
null`.
item

The update hook overwrites a transient FE `adminId` field with the edited route id before calling backend `update-admin-user`; backend persistence is still keyed by `superAdminId`.

Related references

Related pages

pageStaff

Operator documentation for backoffice administrator accounts, including list, create or edit, read-only inspection, and permission review.

pageStaff / Detail Model

Shared detail payload for one admin account, used by both the read-only view page and the edit form.

pageStaff / List

Staff inventory with search, create navigation, view or edit entrypoints, and a restricted demo-admin action.

pageStaff / Permissions

Read-only explanation of the permission matrix shown inside the staff view workspace.

pageStaff / View

Read-oriented staff workspace with overview fields and a dedicated permissions tab.

pageAffiliate Deals / Form

Create and edit form for affiliate deals, including PID, date window, commercial terms, and responsible person.