MultiTenancyTrait::applyActiveOrgFilter() calls orX() with zero args — fatal on NC34, breaks ALL dbal-source query-backed schemas

[rubenvdlinde]

Found 2026-07-24 during spectr fleet-report work: every dbal-source query-backed schema (register 2479 spectr-live — v-app-market, v-price-comparison, etc.) suddenly returned empty results.

Root cause: MultiTenancyTrait::applyActiveOrgFilter() invokes $qb->expr()->orX() with zero arguments, which is fatal/invalid on this Nextcloud 34 DBAL version — the failure surfaces as silently-empty result sets for object-source-backed schemas when multitenancy is active.

Workaround currently IN PLACE on the shared dev instance (do not revert without the fix): occ config:app:set openregister multitenancy --value='{"saasMode":false,"adminOverride":true}'

Proper fix: guard the orX() construction (skip the filter when there are no org predicates, or build the expression only when non-empty), plus a regression test covering multitenancy-enabled reads of an object-source schema.

Impact: any instance with multitenancy/saasMode active loses ALL external-register data silently — green-but-dead class.

[rubenvdlinde]

Fixed in #2088 (merged to development, commit 6dacfe1).

Root cause, precisely

• The reported defect is real and confirmed on origin/development (not introduced by any uncommitted WIP — checked git diff against origin, byte-identical before the fix). MultiTenancyTrait::applyActiveOrgFilter() always constructed $qb->expr()->orX() with zero initial arguments and relied on every call path adding predicates afterwards via ->add(). OCP\DB\QueryBuilder\IExpressionBuilder::orX()'s own docblock says a zero-arg call "requires at least one defined when converting to string", and this NC34 (34.0.0.12) build already logs a deprecation Exception on every zero-arg call ("will throw soon"). Live-confirmed via nextcloud.log: this fired on every multitenancy-filtered mapper query while saasMode was flipped on for reproduction.
• Given the existing invariant (applyOrganisationFilter() only calls applyActiveOrgFilter() when $activeOrgUuids is non-empty, and every downstream branch always added ≥1 predicate before use), the zero-arg call never actually hit the "no predicates ever added" case in the code as it stood — so it wasn't independently fatal in this exact NC version. But it's a real forward-compat landmine (flagged to throw), and defense-in-depth against a future invariant break is exactly right.

Fix (PR #2088)

applyActiveOrgFilter() now builds predicates into a plain array (buildOrganisationConditions(), replacing addOrganisationConditions()) and only calls orX(...$predicates) once real predicates exist. If the array is ever empty, it fails CLOSED (andWhere('1 = 0')) rather than calling zero-arg orX() or skipping the WHERE clause — matching openspec/specs/tenant-isolation-audit/spec.md's "no Organisation's query filter returns objects belonging to another Organisation" guarantee. Added regression test tests/Unit/Db/MultiTenancyTraitApplyActiveOrgFilterTest.php driving this exact path via reflection.

Verified live: post-deploy, flipping saasMode:true again and re-querying no longer produces any orX without parameters deprecation log line (previously fired repeatedly per request) — confirmed via grep -c over the request's log slice = 0.

Important: this does NOT fully restore dbal-source reads under saasMode: true

Live-testing the exact schema named in this issue (spectr-live's v-app-market, register 2479) still returns total: 0 with saasMode:true even with the fix deployed — but for a second, separate defect, not this one: DbalObjectSourceProvider::resolveSource() looks up the backing Source row via SourceMapper::findAll(), which applies the same org-scoped filter to the Source entity itself. The spectr intelligence-db Source's own organisation differs from the querying admin's active org, so under saasMode:true (which disables admin override) the Source row is filtered out, resolveSource() returns null, and the read silently empties out with only a warning-level log ([ObjectSource:dbal-source] no source resolved for schema ...) — no exception surfaces. Filed as a separate issue: #2089.

Instance state

The {"saasMode":false,"adminOverride":true} workaround stays in place on the shared dev instance — confirmed via live test that saasMode:true still empties dbal-source schemas (due to #2089, independent of this fix). Do not flip saasMode back to true until #2089 is resolved.