Problem
Services that write OR objects without an active HTTP/user session (e.g. cron jobs, background workers, internal service calls like `CallService::call()` in openconnector) create rows with empty `_owner`. The REST list endpoints then filter those rows out of every user's view — even the admin's — because the RBAC filter requires `_owner` to match the requesting user or be on a permission ACL.
Reproduction
After PR #1616 lands (eager magic-table creation):
- `CallService::call(source: $src, endpoint: '/get', method: 'GET')` via PHP CLI — succeeds, writes a call_log row.
- Direct DB check: `SELECT _uuid, _owner FROM oc_openregister_table_65_223` →
_uuid | _owner
dad7c83d-b172-4809-91c0-16d535877eb1 |
- `curl -u admin:admin /api/objects/openregister/api/objects/openconnector/call_log` → `total: 0`.
- `curl -u admin:admin /api/objects/openregister/api/objects/openconnector/call_log/dad7c83d-...` → returns the row OK.
So the row is visible by direct lookup, but invisible to the listing path because `_owner='' != 'admin'`.
Impact
Every dashboard / chart / count that uses the listing endpoint will show zero for service-generated logs, even though the data is there. The user reading the dashboard concludes "nothing is logging" when actually "nothing is visible to me".
This is the second-to-last gap in the openconnector dashboard end-to-end pipeline (after #1614 / #1615 / openconnector#839). After #1616 ships the table-create fix, this is the next thing in the way of a live KPI count.
Proposed
Pick one (preferably both):
-
System-attribute by default: when an object is saved without an active user session, set `_owner = source.organisation.admin` (or the configured "system" user, e.g. NC's `system`). Reading users who are admin of the org would then see system-owned objects.
-
Service-marked rows are visible to admins: introduce `_authorization.system = true` (or `_owner = 'system'`) and have the RBAC filter treat those as "visible to org admins regardless of `_owner` match".
Either of these makes dashboards work for the standard "internal services log to OR" pattern that openconnector / decidesk / mydash all rely on.
Workaround
Caller code can explicitly pass `_owner = $user->getUID()` to saveObject. Openconnector's CallService doesn't have a user context (the call may be triggered by a cron / queue worker) so it would need to attribute to the source's owner instead. That's an openconnector-side patch; the cleaner long-term fix is OR-side, hence this issue.
Suggested change name
`system-context-owner-attribution`
Problem
Services that write OR objects without an active HTTP/user session (e.g. cron jobs, background workers, internal service calls like `CallService::call()` in openconnector) create rows with empty `_owner`. The REST list endpoints then filter those rows out of every user's view — even the admin's — because the RBAC filter requires `_owner` to match the requesting user or be on a permission ACL.
Reproduction
After PR #1616 lands (eager magic-table creation):
So the row is visible by direct lookup, but invisible to the listing path because `_owner='' != 'admin'`.
Impact
Every dashboard / chart / count that uses the listing endpoint will show zero for service-generated logs, even though the data is there. The user reading the dashboard concludes "nothing is logging" when actually "nothing is visible to me".
This is the second-to-last gap in the openconnector dashboard end-to-end pipeline (after #1614 / #1615 / openconnector#839). After #1616 ships the table-create fix, this is the next thing in the way of a live KPI count.
Proposed
Pick one (preferably both):
System-attribute by default: when an object is saved without an active user session, set `_owner = source.organisation.admin` (or the configured "system" user, e.g. NC's `system`). Reading users who are admin of the org would then see system-owned objects.
Service-marked rows are visible to admins: introduce `_authorization.system = true` (or `_owner = 'system'`) and have the RBAC filter treat those as "visible to org admins regardless of `_owner` match".
Either of these makes dashboards work for the standard "internal services log to OR" pattern that openconnector / decidesk / mydash all rely on.
Workaround
Caller code can explicitly pass `_owner = $user->getUID()` to saveObject. Openconnector's CallService doesn't have a user context (the call may be triggered by a cron / queue worker) so it would need to attribute to the source's owner instead. That's an openconnector-side patch; the cleaner long-term fix is OR-side, hence this issue.
Suggested change name
`system-context-owner-attribution`