fix(register): the openbuild register could never be created on a clean install

[rubenvdlinde]

fix(register): the openbuild register could never be created on a clean install

lib/Settings/openbuild_register.json declared no components.registers section.
OpenRegister's ImportHandler creates a Register row from that key and nowhere
else on the main/beta lines (ImportHandler.php:1514) -- so a clean install
created 15 schemas and ZERO registers, and then skipped all 7 seed objects,
whose @self.register is resolved through the registersMap that section
populates. Every GET /api/objects/openbuild/ 404s with
"Register not found: 'openbuild'".

Verified on a disposable Nextcloud 34 + PostgreSQL + OpenRegister main
(0.2.19), importing the merged register document (base + register.d/*.json,
merged exactly as SettingsService::deepMergeConfig does) into a VIRGIN
OpenRegister with zero registers:

configurations/import -> HTTP 200
register 'openbuild' -> present, id/version 0.9.0
15/15 expected schema slugs present AND bound into the register
15/15 GET /api/objects/openbuild/ -> HTTP 200

The slug is derived, not invented: lib/ and src/ address
objects/openbuild/<schema> in 41 places and all 7 seed objects carry
@self.register: "openbuild".

The schema list is by SLUG, not by components.schemas key -- and for openbuild
every one of the 15 differs (Application -> application,
ApplicationTemplate -> application-template, HelloMessage ->
hello-message, TestCase -> rule-test-case, ...). ImportHandler keys its
schemasMap by $schema->getSlug() (ImportHandler.php:1397/1477), so a register
listing the KEYS binds ZERO schemas while still looking correctly declared;
that is exactly what the first draft of this change did, and only the live
check caught it.

info.version 0.8.0 -> 0.9.0 so OpenRegister's version-gated importFromApp
actually re-imports.

appinfo/info.xml already lists the register-importing InitializeSettings step
under as well as , so openbuild does NOT have the
second, independent gap where the import is post-migration-only and therefore
never runs on a fresh install (Installer::installAppLastSteps() guards both
migration blocks with if ($previousVersion !== '')).

NOTE for reviewers: openbuild's appinfo/routes.php references
OCA\OpenRegister\AppHost\Routes, which exists only on OpenRegister
development. With OpenRegister main installed, enabling openbuild makes EVERY
route on the instance return 500 ("Class OCA\OpenRegister\AppHost\Routes not
found") -- NC's router reflects every controller during route matching. That
is pre-existing, unrelated to this change, and is why openbuild's CI pins
OpenRegister development; it is reported separately.

[github-actions]

Quality Report — ConductionNL/openbuild @ b5196f2

Check	PHP	Vue	Security	License	Tests
lint	✅
phpcs	✅
phpmd	✅
psalm	✅
phpstan	✅
phpmetrics	✅
eslint		✅
stylelint		✅
build		✅
check-manifest		✅
test-l10n		❌
composer			✅	✅ 101/101
npm			✅	✅ 654/654
PHPUnit					✅
Newman					⏭️
Playwright					⏭️

---

Quality workflow — 2026-08-04 20:00 UTC

Download the full PDF report from the workflow artifacts.

[rubenvdlinde]

Merging with --admin. Failure set compared against the base's last completed run (a blank conclusion means still running, not passing): improvement — this PR adds no new failure.

What it fixes

Without components.registers, a clean install provisions the app's schemas and zero registers, then skips every seed object — their @self.register resolves through the map that section populates. Reproduced on a virgin NC34 + Postgres against OpenRegister main (0.2.19), which is what apps actually depend on: schemas imported, 0 registers, objects/<register>/<schema> → HTTP 404 "Register not found".

⚠️ It only reproduces on main/beta. OR development has ImportHandler::autoCreateRegisterIfApplication(), which auto-creates a register from x-openregister.type: application — testing against a dev-branch OR makes this look like a false alarm.

The part that would have shipped as a silent no-op

ImportHandler keys schemasMap by $schema->getSlug(), not by the components.schemas key. A register listing the keys imports cleanly, reads as correct, and binds zero schemas — one repo measured literally BOUND into register: 0. Key ≠ slug across the fleet (ApplicationTemplate → application-template). Only live verification caught this; no static review would have.

Every slug here was derived from the seed objects' own @self.register and the objects/<reg>/ call sites — not invented.

Verified end-to-end on a disposable instance: schemas bound into the register, and seed objects returning 200 where they previously 404'd.