Summary
Since PR #411 (fix(starter_sp_mis): make registry access control persist and enforce, merged to 19.0 on 2026-08-19), the weekly/dispatched ci-full SP-MIS Demo job fails two spp_registry tests that passed in the 2026-08-16 baseline:
ERROR: TestRegistrantUnlinkPermissions.test_manager_can_unlinkERROR: TestRegistrantUnlinkPermissions.test_officer_plus_manager_can_unlink
odoo.exceptions.AccessError: Registry records are restricted to administrators.
Ask an administrator to make this change, or turn off 'Restrict Registry Edits
to Admin Only' in SP-MIS Settings.
Mechanism
spp_starter_sp_mis ships spp_starter.registry_admin_only_crud = True as the install default (data/config_parameters.xml, deliberately noupdate="1" per OP#1142). Before #411 the restriction was a client-side JS patch (static/src/js/registry_restriction.js), which server-side tests never saw. #411 replaced it with a real guard in models/res_partner.py, so on a fresh SP-MIS demo install the restriction is on and enforced — and spp_registry's unlink-permission tests, which assert that a registry manager can unlink a registrant, now fail whenever they run with the SP-MIS stack loaded.
spp_registry's own module CI stays green (the guard module isn't loaded there); only the full-stack demo runs surface it.
Evidence
Why it matters
The SP-MIS Demo job was already red (#431), so this regression is invisible in the job-level view — it only shows up when diffing failing-test sets between runs. Every additional silent regression accumulating behind a red baseline job makes ci-full less useful as a gate.
Possible directions (not prescribing)
Found during the batch-2 security staging drift re-validation (PR #422): the failure-set diff proved these two errors come from 19.0 (#411), not from the batch.
Summary
Since PR #411 (
fix(starter_sp_mis): make registry access control persist and enforce, merged to 19.0 on 2026-08-19), the weekly/dispatchedci-fullSP-MIS Demo job fails twospp_registrytests that passed in the 2026-08-16 baseline:ERROR: TestRegistrantUnlinkPermissions.test_manager_can_unlinkERROR: TestRegistrantUnlinkPermissions.test_officer_plus_manager_can_unlinkMechanism
spp_starter_sp_misshipsspp_starter.registry_admin_only_crud = Trueas the install default (data/config_parameters.xml, deliberatelynoupdate="1"per OP#1142). Before #411 the restriction was a client-side JS patch (static/src/js/registry_restriction.js), which server-side tests never saw. #411 replaced it with a real guard inmodels/res_partner.py, so on a fresh SP-MIS demo install the restriction is on and enforced — andspp_registry's unlink-permission tests, which assert that a registry manager can unlink a registrant, now fail whenever they run with the SP-MIS stack loaded.spp_registry's own module CI stays green (the guard module isn't loaded there); only the full-stack demo runs surface it.Evidence
ci-fullon 19.0 @ 3939520 (control dispatch, run 32350162352, 2026-08-20): both tests fail.ci-fullweekly on 19.0 (run 31924942721, 2026-08-16, pre-fix(starter_sp_mis): make registry access control persist and enforce #411): both tests pass.Why it matters
The SP-MIS Demo job was already red (#431), so this regression is invisible in the job-level view — it only shows up when diffing failing-test sets between runs. Every additional silent regression accumulating behind a red baseline job makes ci-full less useful as a gate.
Possible directions (not prescribing)
TestRegistrantUnlinkPermissionsaware of the restriction (skip or adjust expectations whenspp_starter.registry_admin_only_crudis active), or have the SP-MIS demo/test fixture disable the flag.registry_admin_only_crud) and the PR feat(registry): consolidate registry configuration into a Registry Settings section #440 registry-settings review findings.Found during the batch-2 security staging drift re-validation (PR #422): the failure-set diff proved these two errors come from 19.0 (#411), not from the batch.