User management is split across the two panels.
The admin panel is shop-scoped and mainly reviews users through company relationships.
The app panel is company-scoped and is where day-to-day company user management happens.
The current codebase defines two user types:
admincompany/admin/appThe current role enum defines:
RequesterOrdererOrdererAdminBudgetAdminCompanyAdminThese roles are used by resource policies and order workflow actions.
Inside the admin panel, user actions are available from a company's related users list.
The admin panel is not the primary place for creating and maintaining all company users in bulk.
The Users resource in the app panel is the main user-management screen for a company tenant.
CompanyAdmin from a companyThe current UserPolicy makes the main Users resource effectively a CompanyAdmin tool for write actions:
viewAny and view policy checksCompanyAdmin can create usersCompanyAdmin can edit usersCompanyAdmin can delete, restore, or force delete usersLocation assignment does not happen on the user form itself.
Instead, users are attached from the Location Users relation manager on a location record.
This means the normal sequence is:
When read directly from the policy classes, the current permission model is:
CompanyAdmin: full write access in the Users resourceBudgetAdmin: no create, edit, delete, restore, or force-delete rights in the main Users resourceOrdererAdmin, Orderer, and Requester: no write access in the main Users resourceThere is also an updateLocationUser helper method in UserPolicy, but the main user-management screens are governed by the resource-level create, update, delete, restore, and force-delete checks above.
The current build does not expose several older documented features, including:
The implemented user-management experience is centered on: