Standing upstream-requirement issue. Filter: upstream.
Gated feature. Cross-account reads of policy-gated collaboration rows. In the pinned jazz-tools@2.0.0-alpha.53, a row whose read policy is an exists-based function condition (e.g. allowRead.where((row) => members.exists.where({groupId: row.groupId, user_id: session.user_id}))) never reaches another account over real sync — not via db.all, not via subscribeAll, not on a fresh boot — while allowRead.always() and direct object conditions ({recipient_user_id: session.user_id}) propagate immediately. Minimal A/B reproduction and pin: the engine canary in package/access/shared_directory_sync_test.ts.
Consequences. The groupAccess and sharedAccess templates' cross-account resource reads are bounded by this at the current pin (the official policy harness enforces the templates correctly in-store; the gap is the sync push/pull path). The shared-field encryption design routes around it deliberately: wrapped keys ride a direct recipient condition, the key directory reads always(), and content protection comes from sealing rather than from read-policy scoping.
Discovered because the pre-existing sync suite never had the second account read a policy-gated resource row — assertions were writer-side only. The canary now pins the gap so a fixing bump fails loudly.
On pin bump. Run the canary; when exists-gated propagation works, revisit the collaboration templates' documented read guarantees, the shared-field read-side guidance, and remove the routing-around notes.
Standing upstream-requirement issue. Filter:
upstream.Gated feature. Cross-account reads of policy-gated collaboration rows. In the pinned
jazz-tools@2.0.0-alpha.53, a row whose read policy is an exists-based function condition (e.g.allowRead.where((row) => members.exists.where({groupId: row.groupId, user_id: session.user_id}))) never reaches another account over real sync — not viadb.all, not viasubscribeAll, not on a fresh boot — whileallowRead.always()and direct object conditions ({recipient_user_id: session.user_id}) propagate immediately. Minimal A/B reproduction and pin: the engine canary inpackage/access/shared_directory_sync_test.ts.Consequences. The
groupAccessandsharedAccesstemplates' cross-account resource reads are bounded by this at the current pin (the official policy harness enforces the templates correctly in-store; the gap is the sync push/pull path). The shared-field encryption design routes around it deliberately: wrapped keys ride a direct recipient condition, the key directory readsalways(), and content protection comes from sealing rather than from read-policy scoping.Discovered because the pre-existing sync suite never had the second account read a policy-gated resource row — assertions were writer-side only. The canary now pins the gap so a fixing bump fails loudly.
On pin bump. Run the canary; when exists-gated propagation works, revisit the collaboration templates' documented read guarantees, the shared-field read-side guidance, and remove the routing-around notes.