Operator guideENstaffadminpermissions

Staff

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

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 module is for

Use Staff to manage backoffice administrator accounts. Operators come here to create a new admin user, edit an existing one, inspect the permission set for one person, and understand which role or group the account belongs to.

Main surfaces

  • Staff / List is the working inventory for all backoffice admin accounts.
  • Staff / Form covers both create and edit flows.
  • Staff / View is the read-oriented workspace for one admin user.
  • Staff / Detail documents the shared backend detail payload used by both the read-only and edit surfaces.
  • Staff / Permissions explains the permission matrix shown inside the view flow.

What operators need to know first

  • The list page is mainly for navigation and inspection. The visible Status badge is informational; no direct staff status toggle was verified on this screen.
  • Role hierarchy is enforced by the backend. Operators cannot assume every role can create or edit every other role.
  • The edit flow is more restrictive than create. The role is not changed from the UI edit form, and group editing is limited by the current role rules in the form.
  • Permission values are not just cosmetic checkboxes. They are stored in the backend permission payload and can inherit from another administrator in specific flows.

Key workflow rules

Create

  • The create flow writes through POST /api/admin/create-admin-user.
  • Role options and group options come from backend-owned lists.
  • A support user can be tied to another admin depending on the creator role and the selected parent relationship.

Edit

  • The edit flow loads one admin detail payload first and then writes through PUT /api/admin/update-admin-user.
  • Password changes are optional on update. The backend only re-encrypts and replaces the password if it actually changed.
  • Email and username remain uniqueness-sensitive on update.

Read-only inspection

  • The read-only page uses the same admin detail source as the edit page.
  • The Permissions tab is the safest place to confirm what access the current record actually has.

Backend verification summary

The first verified backend ownership for this module is in gs-admin-backend:

  • GET /api/admin/get-admins for the list inventory
  • GET /api/admin/admin-details for shared detail data
  • POST /api/admin/create-admin-user for creation
  • PUT /api/admin/update-admin-user for edits
  • GET /api/admin/get-roles for role options
  • GET /api/admin/get-all-group for group options
  • PUT /api/admin/generate-demo for the demo-admin action

No separate gs-casino-backend ownership was verified for the current Staff surfaces.

Related references

Related pages

pageStaff / Detail Model

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

pageStaff / Form

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

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.

pageChallenges / Permissions

Rule-management surface for deciding which users can qualify for challenge creation or visibility.