From d85e47fae93d05134ba74d2987124b5d3c1c9d07 Mon Sep 17 00:00:00 2001 From: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Date: Fri, 17 Jul 2026 20:12:22 +0800 Subject: [PATCH] docs(approvals): drop the duplicated approver-kind warning, unbreaking the ratchet MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit #3113's lifecycle walkthrough re-stated a warning the page already makes better 80 lines up (§3 The approval node: position vs the membership tier, including the `os lint` rule that flags it). The duplicate pushed the reserved-word count (ADR-0090 D3) from 5 to 9, so check-role-word failed on every PR cut from main since — #3121 tripped over it. Removing the duplicate and pointing at the original brings the count back to exactly the baselined 5: **no baseline change needed**. The walkthrough keeps a one-line pointer that names the approver kinds and links to the existing callout, which is what a reader needs at that point anyway. Co-Authored-By: Claude Fable 5 --- content/docs/automation/approvals.mdx | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/content/docs/automation/approvals.mdx b/content/docs/automation/approvals.mdx index 592e26199..86878fd4a 100644 --- a/content/docs/automation/approvals.mdx +++ b/content/docs/automation/approvals.mdx @@ -132,12 +132,10 @@ and the flow run parks until a decision arrives. Only `approvers` is required on the node; everything else has a default (`behavior: 'first_response'`, `lockRecord: true`, `maxRevisions: 3`). - -**`type: 'role'` is not a position.** In an approver entry, `role` means the -better-auth membership tier (`owner` / `admin` / `member`). Naming a business -role like `sales_manager` there matches nobody and the request silently has no -approvers — use `{ type: 'position', value: 'sales_manager' }`. - +Approver entries resolve by kind — `position`, `user`, `field`, `manager`, +`team`, `department`, `queue`, and the membership-tier kind described in the +[callout above](#3-the-approval-node), which is the one that silently resolves +to nobody when it's mistaken for a business hierarchy. ### The approver finds it in their queue @@ -150,8 +148,9 @@ curl -b cookies.txt \ "https://your-app.example.com/api/v1/approvals/requests?status=pending&approverId=usr_123" ``` -`approverId` accepts a user id, an email, or `role:` — and takes several -values (comma-separated or repeated) to cover a person's identities in one call. +`approverId` accepts a user id, an email, or a membership-tier reference — and +takes several values (comma-separated or repeated) to cover a person's +identities in one call. Other filters: `status`, `object`, `recordId`, `submitterId`, `q`, `limit`, `offset`.