You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3f6587c
Browse filesBrowse the repository at this point in the historyBrowse files
fix(plugin-approvals): the read gate reaches the approvals door's visibility in-package, the published ApprovalService type unchanged
The visibility source moves off the class into a module-scoped WeakMap
the constructor fills, reached through requestVisibilitySourceOf, which
the package entry does not re-export; the by-id row read becomes a
module function. ApprovalService's member list equals origin/main's.
Claude-Session: https://claude.ai/code/session_013j5gkUCpqQiti4GgPqqmnt
Co-authored-by: Claude <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: .changeset/22559-approval-request-read-gate.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ A read of `sys_approval_request` through the generic data door (`find`, `findOne
14
14
15
15
Before this, a deployment that granted read on the object served every request of the organization on that door, including the payload snapshots of records the caller cannot open.
16
16
17
-
-**One rule for both doors.** The gate asks `ApprovalService.visibleRequestIdsFor`, which is the approvals door's own visibility. It is not the activity stream's parent-record gate, which admits every reader of the record: the record-reader tier stays off unless the deployment names the object.
17
+
-**One rule for both doors.** The gate asks the approvals service for its own visibility (the same rule `listRequests` and `getRequest` apply), through an in-package handle: the published `ApprovalService` type is unchanged. It is not the activity stream's parent-record gate, which admits every reader of the record: the record-reader tier stays off unless the deployment names the object.
18
18
-**Absence, not refusal.** A request the caller may not see answers a by-id read exactly as a missing one does, `404 RECORD_NOT_FOUND`. A list's `total` and a grouped count are narrowed like its rows. A failed visibility answer denies the read and logs a warning.
19
19
-**Unchanged.** The approvals door, an administrator's view (Setup → Approvals → Requests), and the approval engine's own reads. A deployment that grants no read on the object still answers `403`.
20
20
- The record-reader tier no longer anchors on `sys_approval_request` itself, even when `recordReaderVisibleObjects` names it.
0 commit comments