toga-ai 1.0.342 → 1.0.343
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.
|
@@ -6,8 +6,8 @@ project: API
|
|
|
6
6
|
client: shared
|
|
7
7
|
type: feature
|
|
8
8
|
status: active
|
|
9
|
-
updated: 2026-
|
|
10
|
-
owners: [jcardinal]
|
|
9
|
+
updated: 2026-07-15
|
|
10
|
+
owners: [jcardinal, apeterson]
|
|
11
11
|
files:
|
|
12
12
|
- api2/Component/Api/V2/V2.php
|
|
13
13
|
- _underscore/Model/Core/Surface.php
|
|
@@ -61,7 +61,27 @@ traffic), behavior is **byte-for-byte unchanged** — pure data, zero extra work
|
|
|
61
61
|
`Client.AclRecordScripts` dispatch grant — it 403'd EZ-1 on dev-sandbox until granted, exactly like
|
|
62
62
|
`meta` did. See [surface-resolver](../../_underscore/features/surface-resolver.md).
|
|
63
63
|
|
|
64
|
+
- **The tell that it's the dispatch-grant gate (not record-level READ) failing: the 403 EZ-1
|
|
65
|
+
response carries `identifiers.script` set to the script route** (e.g. `"meta"`). If you see
|
|
66
|
+
`identifiers.script`, chase `AclRecordScripts`, not `AclRecordPermissions`.
|
|
67
|
+
- **Which roles the dispatch check reads depends on the record's `aclDatabase`.** The `surfaces`
|
|
68
|
+
Record has `aclDatabase = CORE`, so `getRecordScriptPhpMethod` matches the caller's **CORE** roles
|
|
69
|
+
(`Core.Roles`: 1=Public, 2=Integrations, 3=Super User, 4=Base) against the `AclRecordScripts` rows —
|
|
70
|
+
even though those rows physically live in each **client** DB. The public login surface authenticates
|
|
71
|
+
as CORE Public(1). (⚠ This corrects the earlier "keyed on client roles" note in
|
|
72
|
+
[surface-resolver](../../_underscore/features/surface-resolver.md) — the two disagree; confirm
|
|
73
|
+
against `V2.php getRecordScriptPhpMethod` before relying on either.)
|
|
74
|
+
- **Seed the dispatch grants in EVERY client DB.** Grant pattern: `meta` + `meta-group` →
|
|
75
|
+
Public(1)/Super User(3)/Base(4); `debug` → Super User(3) only. A client DB missing the grant 403s
|
|
76
|
+
that tenant even though the code and Core metadata are identical — new/pre-existing client DBs
|
|
77
|
+
silently lack it.
|
|
78
|
+
|
|
64
79
|
## Change history
|
|
80
|
+
- 2026-07-15 — Documented the diagnostic tell (`identifiers.script` present on the 403 EZ-1 → it is
|
|
81
|
+
the `AclRecordScripts` dispatch gate, not record READ); clarified the dispatch check reads the
|
|
82
|
+
caller's **CORE** roles because `surfaces.aclDatabase = CORE` (contradicts the earlier "client
|
|
83
|
+
roles" note — flagged for reconciliation); and that the per-role grants (`meta`/`meta-group` →
|
|
84
|
+
1/3/4, `debug` → 3 only) must be seeded in every client DB. (apeterson)
|
|
65
85
|
- 2026-06-30 — Noted the grouped `meta-group` endpoint (batched multi-slug resolve) and that it needs
|
|
66
86
|
its own per-role `AclRecordScripts` dispatch grant (403 EZ-1 until granted). (jcardinal)
|
|
67
87
|
- 2026-06-29 — Documented the second ACL layer: scripted-API dispatch is authorized via
|
package/package.json
CHANGED