Skip to content

uid: T-190 title: Approvals route to a rank, not to one named person β€” retire the single line manager status: todo area: user-management created: 2026-07-27 assignee: unassigned owner: girafeev1 related: T-188

T-190 β€” Anyone senior enough may approve

Why

Raising an approval request today resolves one named person β€” the requester's lineManagerUid β€” and makes them the sole approver. Two consequences, both verified in code 2026-07-27:

  • No line manager configured = you cannot raise the request at all. pages/api/approvals/index.ts (:136) returns a hard 400: "You do not have a line manager configured. Please contact an administrator." Since the field is optional on the invitation and optional in the user editor, this is the default state of anyone nobody remembered to configure.
  • One person is a single point of failure. createApprovalRequest is called with approverUid: userProfile.lineManagerUid (:156) β€” exactly one approver. If that person is away, ill, or has left, the requester is stuck until an admin edits their record.

Owner, 2026-07-27 (verbatim): "lineManagerUid doesn't seem to make sense as I feel that anyone above the role of the invitee should be able to approve it"

Scope

  • Replace the single named approver with a rank rule: an approval request may be actioned by any active user whose standing is above the requester's. What "above" means has to be defined against the badge/role model rather than invented here β€” that model is T-151/T-022 territory and has its own owner, so the ordering must be agreed, not assumed.
  • Decide what happens to a request's notification and email routing when the approver is a pool rather than a person (the Notification Hub's dynamic personnel tokens from T-162 are the natural fit β€” approval_request is already an email-capable kind).
  • Decide whether an approval, once actioned, records who took it (it should β€” the audit value of the current model is that you know who approved; a pool must not lose that).
  • Retire lineManagerUid from the user record, the user editor, and the invitation β€” only after the rule above is live.

Sequencing constraint

The field cannot simply be dropped from the invitation while approvals still read it: newly onboarded people would be created with no approver and hit the 400 above on their first request. The rank rule has to land first, or in the same change.

T-188 leaves lineManagerUid in place on the invitation document for exactly this reason β€” its removal belongs here, not there.

Out of scope

Role/badge semantics themselves. This task consumes whatever ordering the badge model defines; it does not invent a new hierarchy.

Source

Split out of T-188 at the owner's request, 2026-07-27, while reviewing the invitation document's structure. Findings verified against pages/api/approvals/index.ts, components/approvals/ApprovalRequestModal.tsx, lib/rbac/invitations.ts and pages/api/admin/users/[uid].ts. Source: User Management Β· https://claude.ai/code/session_01GGT5n9vCxKWoUQSRAfMSiW