Skip to main content

Create or edit a business owner

The current source defines Business owner accounts as user level 2 and exposes profile and business-assignment surfaces. This page documents those source paths without creating an account, reading personal data, or changing identity, credentials, roles, sessions, or assignments.

Source-only access boundary

The /users/business-owners route allows level 0. Its Users sidebar parent also excludes read-only account types. Route presence is not API authorization, and no authenticated request was made.

Source-defined create surface​

  1. The page fixes the list and new-user type to Business owner (level 2).
  2. The shared form derives visible fields from project configuration.
  3. The form can include contact, credential, phone, and image inputs.
  4. Submission is a persistent user-registration request.
  5. Do not exercise this sequence for documentation.
New Business owner form using a synthetic email and password

The fixed source validates configured fields and exposes an eight-character password boundary. API source separately validates identity fields and uniqueness. These are contract observations, not permission to collect or submit an email, phone number, password, or photo.

Business-assignment boundary​

For a level-2 record, the detail menu exposes Businesses separately from Profile, Saved places, and Orders. The controller submits the selected business collection through the user-update contract. API source restricts assignment changes to an administrator and can replace relationship state. No business list was read and no assignment was changed.

Profile and credential boundary​

The shared editor can expose configuration-driven profile fields, timezone, phone, password, image, enabled state, and role selection. An update request can alter identity and access. API source prevents a user from changing their own level, validates changed contact data, and treats password changes as session-affecting. No field value or session was inspected.

Fail-closed interpretation​

  • Contact, password, enabled-state, role, deletion, and assignment controls are writes.
  • Password update source includes other-session revocation logic; no session outcome is claimed.
  • Protected-user and authorization checks can reject changes.
  • A client success message is not deployed-effect evidence.

Re-entry required for positive guidance​

Positive procedural guidance requires immutable Dashboard/API serving receipts and an approved synthetic identity fixture with all email, phone, credential, session, role, assignment, and outbound effects intercepted. Until then, the page remains source-only.