Users
Current source defines Users as a set of authenticated account-management surfaces. Each route starts with a user-level filter and shares list, search, detail, export, state-change, creation, and deletion controls. This page documents fixed-source boundaries only; it does not prove hosted access, returned records, or a successful action.
Mounting a user list performs authenticated reads of personal and operational data. GET and HEAD are not presumed safe. Do not open live records, search real identities, export data, change account state or role, create or delete users, edit assignments, inspect sessions, or capture personal information.
Route and sidebar boundaries
The Customers, Business Owners, Call Center Agents, and Admins routes are restricted to level-0 administrators. The Users sidebar parent also requires level 0 and excludes read-only state. Call Center Agents adds an Enterprise-plan condition in the sidebar; its direct route does not repeat that plan check.
Source-defined user groups
| User group | What it shows | Availability |
|---|---|---|
| Customers | User level 3 | Users menu; level-0 route |
| Business owners | User level 2 | Users menu; level-0 route |
| Call Center Agents | User level 9 | Users menu only for Enterprise; level-0 route |
| Admins | User level 0 | Users menu; level-0 route |
Each of these pages opens as a filtered view of the shared user list. The role used by a page does not, by itself, determine every action that the API will allow.
Professionals is a separate sidebar item rather than a Users submenu. Its item expression names levels 0 or 2 plus the appointments feature/add-on, but the enclosing My addons parent requires level 0, add-ons availability, and no read-only state. Effective sidebar reachability is therefore level 0 only with those parent and item gates, while the direct route permits levels 0, 2, and 5. A direct-route guard does not prove feature availability or API authorization.
Authenticated reads and private fields
The shared controller performs a paginated user request on mount and repeats it when user type, active state, search, verification, occupation, order-count, or advanced filters change. Returned fields can include names, email addresses, phone numbers, addresses, birth dates, locations, verification states, order counts, wallets, push tokens, business relationships, and other role-specific data.
Opening a detail from a direct query can perform an additional user read. Detail tabs can trigger further reads for addresses, orders, assigned businesses, metadata, wallets, or other private surfaces. No list, detail, filter, tab, or record was opened for this documentation.
Persistent and outbound effect surfaces
Current source exposes these action classes across the user pages:
- the row or detail Enable switch immediately submits an account update;
- profile save can change identity, contact, password, image, role, schedule, or other configured fields;
- Add user creates an account;
- CSV requests can queue a private-data export job;
- single delete mutates account identifiers, soft-deletes the record, writes a log, and invokes the inspected
users_deleteplugin actions; - bulk delete mutates eligible identifiers, deletes eligible records, and writes logs without that plugin action in the inspected method; it can report a protected-user error after eligible deletions already occurred;
- Custom fields can read, create, or delete user metadata;
- business-assignment controls can replace relationship sets.
Current API source blocks disabling or deleting a protected user and blocks an administrator from deleting itself, but client confirmation and error messages are not proof of atomicity or harmless failure. Password updates can also revoke other sessions. None of these effects was executed.
Source-only authorization boundary
Dashboard route levels and sidebar visibility are not backend authorization. Current API source applies method-specific roles and record-level checks; for example, list, export, update, assignment, delete, and professional operations have different guards. A returned button or route is not evidence that a hosted request is permitted.
What remains unverified
Without immutable Dashboard/API serving receipts and approved synthetic identities with PII, credentials, sessions, outbound messaging, and all writes isolated, this page does not claim deployed availability, authorization, returned fields, export completion, successful updates/deletes, session effects, assignment effects, or safe retry.