feat(registry): consolidate registry configuration into a Registry Settings section - #439
Closed
emjay0921 wants to merge 1 commit into
Closed
feat(registry): consolidate registry configuration into a Registry Settings section#439emjay0921 wants to merge 1 commit into
emjay0921 wants to merge 1 commit into
Conversation
…p it per program Every card on the Configuration tab was filled through an inline list with a manager_ref_id Reference field. That control asks for a model and then a record of it, and both halves offered other programs' managers — the Reference picker directly, and on the Many2many cards the link dialog behind "Add a line". A manager picked that way keeps running against the program it was created for, so the second program's form showed configuration that was never going to apply to it. Adding now goes through one dialog for every card: which method, what to call it, then the method's own form to configure it. The methods on offer come from the wrapper's _selection_manager_ref_id(), so a module that registers one is included without editing the wizard, and a category with none says so instead of opening an empty list. Eligibility, Entitlement, Cycle, Compliance, Payment and Notifications now share one shape: a badge, an Add button, a row per method with its own cog, an empty state, and an Edit button only when there is exactly one method — it used to open the first of several silently. Notifications was the last section still rendered as a bare group and is now a card like the rest. The rows deny both 'create' and 'link'; for a Many2many the renderer reads the second, which is why create="0" alone never suppressed the row. 'unlink' is untouched, so the x still removes a method. Isolation no longer depends on the form: create and write refuse a manager owned by another program, and duplicating a program copies its methods instead of linking the original's. Only what a write adds is checked, so a database that already holds a cross-program link stays editable and the link can be removed. Duplicate Detection is deliberately untouched here — its card is being converted under OP#1171 on another branch. The isolation rules still cover it.
Contributor
Author
|
Closing: opened from the wrong head branch by mistake — this carried the OP#1172 branch's commits under an OP#1009 title. Reopening against feat/1009-registry-settings. Nothing here was reviewed or merged. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 19.0 #439 +/- ##
==========================================
+ Coverage 72.24% 73.20% +0.95%
==========================================
Files 419 481 +62
Lines 29813 32339 +2526
==========================================
+ Hits 21539 23673 +2134
- Misses 8274 8666 +392
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why is this change needed?
Registry configuration lived in two places (OP#1009):
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?
spp_registry, mirroring Programs Settings, carrying Restrict Registry Edits to Admin Only.get_values/set_valueskeepspp_farmer_registry.registry_admin_only_crudandspp_starter.registry_admin_only_crudin 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.base.menu_administration). The API V2 security compliance manifest is updated to match.spp_security.group_spp_adminandspp_registry.group_registry_config_admin. Additive viaCommand.link, so stock system / access-rights visibility is preserved and every section under Settings still enforces its own group gate.res_config_settings_views.xml, which the manifest loads beforemain_view.xmlso 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.0in, all five affected modules installed together against current19.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.0and unrelated to this branch:spp_registry/tests/test_phone_number.py::test_unparseable_phone_falls_back_to_originalexpects"abcxyz"to fall through tophone_sanitized, whilespp_base_common/models/phone_number.py:41raisesPhone number must not contain letters.from itscreate()override. Both files are unchanged here and untouched by this branch. It stays hidden in CI becausespp_registrydoes not depend onspp_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
registry_admin_only_crud— both keys follow the toggle in both directions.Related links