@forumone/throughline-approvals 0.8.3 → 0.8.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +36 -0
- package/package.json +3 -3
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,41 @@
|
|
|
1
1
|
# @forumone/throughline-approvals
|
|
2
2
|
|
|
3
|
+
## 0.8.4
|
|
4
|
+
|
|
5
|
+
### Patch Changes
|
|
6
|
+
|
|
7
|
+
- d02772f: `get_approval_status` now refuses an unauthenticated caller, and answers only
|
|
8
|
+
the requester or a member of an approver group.
|
|
9
|
+
|
|
10
|
+
It had no authorization check of any kind. The handler was `async (input) =>` —
|
|
11
|
+
the signature did not accept `ctx`, so there was nothing to check against — and
|
|
12
|
+
it `findByID`d an arbitrary `approvalId` at the Local API default of
|
|
13
|
+
`overrideAccess: true`, returning the target, the requester, the approver
|
|
14
|
+
groups, the decision and the decision notes. The other four tools on this
|
|
15
|
+
server all check `ctx.user`, which made this the one approvals tool that still
|
|
16
|
+
answered when the rest correctly denied. Audit 04 F-20.
|
|
17
|
+
|
|
18
|
+
The rule is the union of what the two list tools already show a caller —
|
|
19
|
+
`list_my_requests` returns the approvals they requested, `list_pending_approvals`
|
|
20
|
+
the ones routed to their groups — so the by-id read agrees with the by-list
|
|
21
|
+
reads instead of being a way around them. No admin bypass, because
|
|
22
|
+
`respond_to_approval` has none either and a second policy on the same collection
|
|
23
|
+
is how the two drift.
|
|
24
|
+
|
|
25
|
+
A refused read returns `Approval not found`, the same sentence as a genuine
|
|
26
|
+
miss: ids are sequential, and a distinguishable refusal enumerates who is asking
|
|
27
|
+
whom to approve what.
|
|
28
|
+
|
|
29
|
+
**Behavioural change for consumers.** A `get_approval_status` call arriving with
|
|
30
|
+
no `ctx.user` now returns `{ error: 'Must be authenticated…' }` instead of the
|
|
31
|
+
approval. In practice that is every `Bearer`-authenticated MCP call, because
|
|
32
|
+
`@payloadcms/plugin-mcp` does not assign `req.user` — the same fact that made
|
|
33
|
+
the four gated tools deny and this one answer.
|
|
34
|
+
|
|
35
|
+
- Updated dependencies [d02772f]
|
|
36
|
+
- @forumone/throughline-core@0.9.1
|
|
37
|
+
- @forumone/throughline-publishing@0.9.4
|
|
38
|
+
|
|
3
39
|
## 0.8.3
|
|
4
40
|
|
|
5
41
|
### Patch Changes
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@forumone/throughline-approvals",
|
|
3
|
-
"version": "0.8.
|
|
3
|
+
"version": "0.8.4",
|
|
4
4
|
"description": "Conversational approval workflow server for Throughline. Provides the approval resolver the publishing server consumes plus MCP tools for requesting and responding to approvals.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./dist/index.js",
|
|
@@ -42,9 +42,9 @@
|
|
|
42
42
|
},
|
|
43
43
|
"dependencies": {
|
|
44
44
|
"zod": "^3.23.0",
|
|
45
|
-
"@forumone/throughline-core": "0.9.
|
|
45
|
+
"@forumone/throughline-core": "0.9.1",
|
|
46
46
|
"@forumone/throughline-plugin-contract": "0.4.1",
|
|
47
|
-
"@forumone/throughline-publishing": "0.9.
|
|
47
|
+
"@forumone/throughline-publishing": "0.9.4"
|
|
48
48
|
},
|
|
49
49
|
"devDependencies": {
|
|
50
50
|
"@types/node": "^24.13.2",
|