fix: Repair step fails with 'Access denied' when importing app configurations via CLI

[rubenvdlinde]

Problem

When apps (e.g. Pipelinq, Procest) trigger their repair step to import configuration into OpenRegister via occ CLI commands (maintenance:repair, app:enable, app:update), the import fails with:

Failed to import configuration for app pipelinq: Access denied: You do not have permission to create configuration entities.

This blocks:

• CI/CD: Playwright E2E tests cannot run because schemas are never loaded
• Fresh installs: App schemas may not load if the repair runs in a context without admin permissions
• Docker environments: occ maintenance:repair during container setup fails silently

Root Cause

OpenRegister's ConfigurationService (or the import pipeline it calls) enforces RBAC checks even when called from CLI context (occ). CLI commands run as the system user without a logged-in Nextcloud user, so RBAC permission checks fail.

Expected Behavior

When importFromApp() is called from a repair step (CLI context), RBAC should be bypassed — repair steps are trusted system operations that must always succeed regardless of user context.

Reproduction

# In a fresh Nextcloud with OpenRegister + Pipelinq installed:
docker exec nextcloud php occ maintenance:repair
# Or:
docker exec nextcloud php occ app:disable pipelinq && docker exec nextcloud php occ app:enable pipelinq

Both produce the "Access denied" error in the Nextcloud log.

Suggested Fix

In the configuration import path, detect CLI context and skip RBAC checks when running from the command line. The existing seed data import already does this pattern (`_rbac: false`), but the configuration entity creation does not.

Impact

• All Conduction apps that use OpenRegister repair steps for schema loading
• CI Playwright tests blocked (31 of 32 tests fail due to missing schemas)
• Affects: Pipelinq, Procest, OpenCatalogi, Docudesk, LarpingApp, SoftwareCatalog

CI Evidence

Pipelinq CI run: https://github.com/ConductionNL/pipelinq/actions/runs/23479271505