Follow-up to the read-side RBAC deny-test vertical slice (#359). Get-by-key reads return 403 when the caller lacks the permission, but search/list endpoints behave differently: Camunda applies row-level filtering — a scoped user gets 200 with an empty items list, not a 403 (see search-authorization-api.spec.ts in the OC e2e suite, cited in #359).
Scope: a distinct assertion shape for */search (and list) read endpoints — as a zero-grant / scoped user, expect 200 + items: [] (or filtered subset), rather than a deny status. Likely a separate scenario kind (e.g. auth-filter) and emitter assertion.
Why separate: it's a different oracle from the 403 deny used for get-by-key, so it doesn't fit the auth-deny path cleanly.
Relates to #359.
Follow-up to the read-side RBAC deny-test vertical slice (#359). Get-by-key reads return 403 when the caller lacks the permission, but search/list endpoints behave differently: Camunda applies row-level filtering — a scoped user gets 200 with an empty
itemslist, not a 403 (seesearch-authorization-api.spec.tsin the OC e2e suite, cited in #359).Scope: a distinct assertion shape for
*/search(and list) read endpoints — as a zero-grant / scoped user, expect 200 +items: [](or filtered subset), rather than a deny status. Likely a separate scenario kind (e.g.auth-filter) and emitter assertion.Why separate: it's a different oracle from the 403 deny used for get-by-key, so it doesn't fit the
auth-denypath cleanly.Relates to #359.