Editing a user role in Settings → Users does not persist

[bdunncompany]

Reproduction

1. Settings → Users
2. Edit on a user with role X
3. Change role dropdown to Y, Save

Result: dialog closes (no error), row in the table still shows X. The join-table row is unchanged.

Root cause

The Edit dialog (apps/web/src/components/settings/UsersPage.tsx:197-218, handleEditSubmit) submits:

PATCH /users/:id
body: { email, name, roleId, orgAccess?, orgIds? }

The API validator (apps/api/src/routes/users.ts:73-76, updateUserSchema) is:

z.object({
  name: z.string().min(1).max(255).optional(),
  status: z.enum(['active','invited','disabled']).optional()
})

It is not .strict(), so roleId is silently dropped. The handler (apps/api/src/routes/users.ts:895-991) writes only name/status to the users table; the role join tables are never touched. Response is 200, and fetchUsers() reloads showing the unchanged role.

The dedicated endpoint that writes role (apps/api/src/routes/users.ts:1042-1114, POST /users/:id/role, writes to partnerUsers.roleId / organizationUsers.roleId) is not invoked by the Edit flow.

The name field also goes along in the PATCH body, which is why the !data.name && !data.status 400 guard does not fire — the request returns 200 with name-as-no-op and the role silently unchanged.

Proposed fix

Make handleEditSubmit POST the role separately when values.roleId is set, in addition to (or instead of) the name PATCH.

if (values.roleId) {
  const roleRes = await fetchWithAuth(`/users/${selectedUser.id}/role`, {
    method: 'POST',
    body: JSON.stringify({ roleId: values.roleId })
  });
  if (!roleRes.ok) throw new Error('Failed to update role');
}

Optional hardening (separate concern): make updateUserSchema .strict() so silently-dropped fields surface as 400s in future.

Test: Vitest component test that mocks the Edit flow, picks a different role, and asserts fetchWithAuth was called with POST /users/:id/role and the new roleId.

Happy to open the PR if this looks like the right shape.

[ToddHebebrand]

Thanks @bdunncompany — confirmed, and the analysis is exactly right. The root cause class is the silent field-drop: updateUserSchema not being .strict() means roleId is dropped before the handler ever sees it, the name no-op keeps the 400 guard from firing, and the 200 makes it look successful. Green light on the fix.

Couple of small preferences on scope:

• Ship the .strict() hardening in the same PR, not deferred. The dropped-roleId symptom and the silent-drop are the same bug — fixing only the Edit flow leaves the next silently-dropped field waiting to bite. With .strict() on, an unexpected key surfaces as a 400 instead of a no-op 200.
• Only POST the role when it actually changed (values.roleId !== selectedUser.roleId). Avoids an unnecessary write + audit-log entry on every name-only edit.
• Keep the name PATCH and the role POST independent — if the role POST fails, surface the error and don't swallow it (no silent partial save).
• The Vitest test you described is the right shape; please also assert the role POST is not sent when the role is unchanged.

Open as a draft and I'll review.

[ToddHebebrand]

Correction to my comment above — the change-detection guard I suggested was wrong. selectedUser (the User type in UserList.tsx) has no roleId field; it carries role (the role name). So values.roleId !== selectedUser.roleId compares against undefined, is always true, and won't typecheck cleanly. The form already resolves the current role id correctly for its defaultValue (around UsersPage.tsx:348, roles.find(r => r.name === selectedUser.role)?.id) — gate on that instead:

const currentRoleId = roles.find(r => r.name === selectedUser.role)?.id;
if (values.roleId && values.roleId !== currentRoleId) {
  // POST /users/:id/role
}

Also a small correction to the body shape I quoted: the edit flow sends { email, name, roleId } (no orgAccess/orgIds — those are invite-path only).

Everything else stands: the PATCH silently strips roleId because updateUserSchema isn't .strict(), the !data.name && !data.status 400 guard at users.ts:906-908 doesn't fire because name is always sent, and the role only persists via POST /users/:id/role (users.ts:1042-1114). The .strict() hardening recommendation also stands.

[bdunncompany]

Draft PR up at #713. All four refinements folded in:

• .strict() on updateUserSchema (hardening in same PR, not deferred).
• Role-change guard uses roles.find(r => r.name === selectedUser.role)?.id per the correction — selectedUser has no roleId field on the User type.
• PATCH name and POST role are independent; role POST errors surface to the user, not swallowed.
• Tests: web asserts POST sent on role-change and NOT sent when unchanged; API asserts PATCH with extra roleId returns 400 (and extra arbitrary field returns 400, defense in depth).

apps/api: 14/14 tests pass. apps/web: 2/2 tests pass. tsc clean on both.

[ToddHebebrand]

Shipped — landed on main in #713 (merged 2026-05-17).

Root cause was the silent field-drop: updateUserSchema wasn't .strict(), so roleId was dropped before the handler and the name no-op kept the 400 guard from firing — a 200 that did nothing. The fix folds in the .strict() hardening, a role-change guard keyed on roles.find(r => r.name === selectedUser.role)?.id, surfaced role-POST errors, and web + API tests.

Thanks @bdunncompany for the precise root-cause. Closing as resolved — reopen if role changes still don't stick.