Pasco Digital New

1. Branch Admin could create a user and then lose it — fixed This was the single biggest functional fix in the window, and it took three commits. The dead end: V685 gave Branch Admin users:view:branch, which narrows the Users grid to people assigned to the admin's own branches. But the create-user flow never assigns a branch — branch assignment is a separate step you reach by clicking the row in the grid. Because branch_staff is LEFT JOINed and NULL IN (...) evaluates to NULL, the brand-new user vanished from the grid the instant it was saved. The Branch Admin could never reach the modal that would have made it visible. The account was stranded until a full ADMIN stepped in. users.created_by added (V735) — stamped by UserCreationService, which had always received the creator's id as an argument and simply thrown it away because there was nowhere to put it. All four scope query sites now also match bs.branch_id IS NULL AND u.created_by = :currentUserId, so you keep sight of the branch-less users you created — and only those. The moment a branch is assigned, the row falls back under the normal branch rule. Deliberately not backfilled: there's no historical record of who created existing accounts, and guessing would hand accounts to the wrong branch admin. Pre-existing stranded users stay ADMIN-only to clear. The endpoint guard (assertWithinBranchScope) got the same allowance, otherwise the row would list but 403 on open. FK is ON DELETE SET NULL, with a partial index on the non-NULL rows. "Manage Branches" modal offered branches it couldn't use — the "Add Branches" tab listed every branch in the organisation to a branch-scoped admin, and any choice outside their own branches failed the submit with "You do not have permission to access this resource." The read side and the write guard had drifted apart. Both now go through one method, resolveBranchStaffScope. The "Current Branches" tab gained an opt-in callerScoped flag so it only lists branches whose Remove action can actually succeed. Opt-in on purpose — the mobile driver screens use the same endpoint just to display a driver's branches, and scoping it by default would silently blank out branches outside the viewer's scope. "Manage Roles" / "Manage Groups" always failed for Branch Admin (V737) — both buttons render on users:manage_roles / users:manage_groups, which Branch Admin holds, but the endpoints behind them are gated on roles:assign_users / groups:assign_users, which it did not. Guaranteed dead end, every time. The grant ships with three guard fixes that had to land with it, because the grant would not have been safe alone: GroupController never applied assertTargetNotProtected — so groups:assign_users alone would have let someone re-group an ADMIN account by posting its id directly. Added to all three group user-assignment endpoints. Neither RoleController nor GroupController applied assertProfileBranchScope — the "only users in my branches" property was enforced purely by which rows the grid lists, which is a frontend constraint, not a security boundary. Added to both. /roles/dropdown/for-user now hides protected roles from non-administrators, so the modal stops offering the four roles the guard would refuse anyway. Net reach: a Branch Admin can assign any of the 64 non-protected roles, and any group, to ordinary users in its own branches. It cannot mint an ADMIN or another Branch Admin. Profile page header stuck on "Loading…" forever — profile/page.tsx gated the "viewing someone else's profile" data fetch and all nine admin section headers on isAdmin. A Branch Admin holds user_profile:view_all but not admin:access, so the header never resolved a name, employee id or role. All eleven checks swapped to canViewProfile.