feat(registry): consolidate registry configuration into a Registry Settings section

[emjay0921]

Draft: QA is re-testing the branch now (OP#1009 moved back to In testing). It passed on 12 August against an 8 June 19.0; 19.0 has since moved 438 commits and has been merged in, so the earlier pass no longer certifies what is here. Marking ready once QA confirms.

Why is this change needed?

Registry configuration lived in two places (OP#1009):

• the Configuration menu inside the Registry app
• Farmer Registry Settings / SP-MIS Settings in the Settings app, each carrying its own copy of the same toggle

The ticket asks for one Registry Settings section in Settings, equivalent to Programs Settings, with the registry configuration moved there — including superuser configuration such as API V2, which sat under Registry → Configuration.

How was the change implemented?

• New Registry Settings section in spp_registry, mirroring Programs Settings, carrying Restrict Registry Edits to Admin Only.
• One toggle, both legacy keys. get_values/set_values keep spp_farmer_registry.registry_admin_only_crud and spp_starter.registry_admin_only_crud in sync, so the Farmer Registry and SP-MIS controllers keep reading their own parameter unchanged — no migration and no change to how the restriction is enforced. The now-duplicate Farmer Registry Settings and SP-MIS Settings sections and their field definitions are removed.
• Superuser configuration relocated. Registry → Configuration, and the API V2 and Import Match menus hanging off it, move under a new Registry group in the Settings app (base.menu_administration). The API V2 security compliance manifest is updated to match.
• Two personas granted the Settings app so they can reach the new location: spp_security.group_spp_admin and spp_registry.group_registry_config_admin. Additive via Command.link, so stock system / access-rights visibility is preserved and every section under Settings still enforces its own group gate.
• The parent menu is declared in res_config_settings_views.xml, which the manifest loads before main_view.xml so the reference resolves.

New unit tests

spp_registry/tests/test_res_config_settings.py — the Registry Settings section reads and writes the toggle, and both legacy parameter keys stay in sync in each direction, which is the property that replaces a data migration.

Unit tests executed by the author

After merging 19.0 in, all five affected modules installed together against current 19.0 — spp_registry, spp_starter_sp_mis, spp_farmer_registry, spp_api_v2, spp_import_match: 1069 tests, 0 failed, 1 error.

That one error is pre-existing on 19.0 and unrelated to this branch: spp_registry/tests/test_phone_number.py::test_unparseable_phone_falls_back_to_original expects "abcxyz" to fall through to phone_sanitized, while spp_base_common/models/phone_number.py:41 raises Phone number must not contain letters. from its create() override. Both files are unchanged here and untouched by this branch. It stays hidden in CI because spp_registry does not depend on spp_base_common, so the per-module matrix never installs them together; it surfaces only in a combined install like the one above. Raising it separately.

How to test manually

1. Settings → a Registry Settings section appears, in the same style as Programs Settings, containing Restrict Registry Edits to Admin Only.
2. The old Farmer Registry Settings / SP-MIS Settings sections are gone.
3. Turn the toggle on: a non-admin registry user can still read registrants but cannot create, edit or delete. Turn it off: they can edit again.
4. Settings → Technical → System Parameters, search registry_admin_only_crud — both keys follow the toggle in both directions.
5. Registry → Configuration no longer holds API V2 or Import Match; both are under Settings → Registry and work as before.
6. As OpenSPP Administrator and as Registry Configuration Admin: the Settings app is visible and Settings → Registry is reachable, with everything else under Settings still gated.

Related links

• OP#1009 — https://projects.acn.fr/work_packages/1009

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.71%. Comparing base (0820667) to head (76a05e7).
⚠️ Report is 7 commits behind head on 19.0.

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #440      +/-   ##
==========================================
+ Coverage   72.24%   72.71%   +0.46%     
==========================================
  Files         419      555     +136     
  Lines       29813    37892    +8079     
==========================================
+ Hits        21539    27553    +6014     
- Misses       8274    10339    +2065     

Flag	Coverage Δ
spp_analytics	93.25% <ø> (ø)
spp_api_v2	79.99% <ø> (?)
spp_api_v2_change_request	66.53% <ø> (ø)
spp_api_v2_cycles	71.03% <ø> (ø)
spp_api_v2_data	77.77% <ø> (ø)
spp_api_v2_entitlements	70.23% <ø> (ø)
spp_api_v2_gis	71.57% <ø> (ø)
spp_api_v2_products	65.86% <ø> (?)
spp_api_v2_programs	92.22% <ø> (ø)
spp_api_v2_service_points	71.03% <ø> (ø)
spp_api_v2_simulation	71.19% <ø> (?)
spp_api_v2_vocabulary	57.75% <ø> (?)
spp_approval	50.34% <ø> (?)
spp_base_common	91.07% <ø> (ø)
spp_farmer_registry	88.46% <ø> (?)
spp_import_match	84.16% <ø> (?)
spp_programs	65.27% <ø> (ø)
spp_registry	87.51% <100.00%> (+0.36%)	⬆️
spp_security	69.56% <ø> (ø)
spp_starter_sp_mis	80.00% <ø> (-6.67%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
spp_farmer_registry/models/__init__.py	100.00% <ø> (ø)
spp_registry/models/__init__.py	100.00% <100.00%> (ø)
spp_registry/models/res_config_settings.py	100.00% <100.00%> (ø)

... and 137 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gonzalesedwin1123]

The consolidation design is right — one toggle, dual legacy keys kept in sync so neither starter's controller changes, and the Settings-app grant done through menu group_ids with Command.link rather than an implied_ids escalation, which is exactly the mechanism our security posture wants. The central toggle also stores "False" explicitly in set_values, so the OP#1142 off-is-unrepresentable trap is avoided. compliance.yaml matches the menu move. All of that verified out.

Three findings, one of them functional:

1. MAJOR — the granted personas can open Registry Settings but cannot save it

res.config.settings.execute() refuses non-administrators (odoo/addons/base/models/res_config.py:366 — if not self.env.is_admin(): raise AccessError(...)), and is_admin means superuser or base.group_erp_manager (res_users.py:1181). Neither spp_security.group_spp_admin nor spp_registry.group_registry_config_admin has or implies that group — the implication deliberately runs the other way (base.group_system implies group_spp_admin, spp_security/security/groups_admin.xml:38).

So the grant delivers, to exactly the personas it exists to serve, a settings form that throws "Only administrators can change the settings" on Save. The relocated Configuration menus (API V2, Import Match) genuinely work — they're ordinary actions with their own gates — but General Settings is reach-without-use. QA passed because the walkthrough ran as admin/admin (a base.group_system user), and the persona checks in the test guide verified reachability, not saving; the PR's three unit tests cover the key-sync logic only.

Options, in order of preference:

1. Hide menu_registry_settings_general from non-erp-manager users (leave the Configuration menus granted as they are) and say in the section help that changing the toggle requires a system administrator. Honest UI, no security change.
2. Give the toggle a dedicated, writable form outside res.config.settings, gated on group_registry_config_admin — more work, but delivers the ticket's intent for those personas.
3. Granting base.group_erp_manager to these groups is a real privilege escalation and would need Edwin's explicit sign-off — recommend against, consistent with the #327/#329 fixes.

Whichever way: please add a test that saves the settings as each persona, so this class of gap can't pass green again.

2. Blocker — structural collision with approved PR #411

This PR deletes spp_starter_sp_mis/models/res_config_settings.py. #411 (approved, awaiting a merge gate) rewrote that file — and its res_partner.py imports REGISTRY_ADMIN_ONLY_CRUD_PARAM from it. Merged in the wrong order, spp_starter_sp_mis fails to load with an ImportError; merged in the other order, the branches conflict textually. Recommended sequence: #411 lands first, then this PR rebases — keep the constant (move it into res_partner.py, or keep a slim res_config_settings.py holding only the constant), and delete only the field and set_values override that the central toggle supersedes. Your dual-key design means #411's migration, noupdate fix and enforcement all remain fully valid underneath this PR.

3. Blocker — no version bumps on the five released modules

spp_registry, spp_farmer_registry, spp_starter_sp_mis, spp_api_v2, spp_import_match — all touched, none bumped, and this PR is almost entirely data (menus re-parented, sections removed, new view/menu records). Your own QA guide documents the failure mode: partial upgrades leave stale sections and menus behind. Per the settled convention: bumps + HISTORY in the PR, numbers reconciled at merge time (note spp_registry now has its own ordering: #418 pending at 19.0.2.1.5, plus #437 and this PR).

Minor

• get_values's "any explicit True wins" is fine under the documented at-most-one-key assumption; a pre-#440 database with both starters and drifted keys re-syncs on first save — acceptable, worth one line in HISTORY.
• The base.menu_administration override lives in spp_registry data, so the links linger if the module is ever uninstalled — cosmetic, no action needed.

With #1 resolved (option 1 is a small change), the bumps added, and the #411 sequencing agreed, this is an approve.