security(roles): scope program/CR roles to Tier-3 registry read (drop registry-search menu)

[gonzalesedwin1123]

Problem

Role links added in the OP#951 menu audit gave several program/CR-scoped roles the Tier-2
spp_registry.group_registry_viewer group:

• spp_programs: Program Viewer
• spp_change_request_v2: CR Requestor, CR Local Validator, CR HQ Validator

group_registry_viewer gates the standalone Registry Search portal menu
(spp_registry_search.menu_registry_search) — a broad registrant-PII enumeration surface (name, ID
number, phone, email) — on top of the registrant read ACLs. So a read-only "Program Viewer" (and the
CR roles) got the full registry browse/search UI, not just the registrant data needed for the
program/CR records they work with.

Important nuance (report framing corrected): OpenSPP does not scope the registry per-program.
Row-level need-to-know is area-based (spp_area rule_res_partner_area_filter, keyed on
user.center_area_ids, populated from local role assignments); it is a no-op for global roles, which
see the whole registry by design. group_registry_restrict_self scopes to the user's own partner
(self-service), not per-program. So this change does not (and cannot, without a new feature) make these
roles see "only their program's beneficiaries" — it removes the Registry Search UI surface while
leaving the underlying RPC read governed by the area filter. Severity: medium (over-broad PII
enumeration UI for program/CR roles).

Fix

Switch the four roles from Tier-2 group_registry_viewer to Tier-3 group_registry_read:

• Tier-3 group_registry_read grants the same registrant read ACLs on res.partner,
  spp.registry.id, spp.phone.number (defined in spp_base_common) — so all registrant
  cross-reference reads keep working — but it does not gate the Registry app menu.
• The CR roles also imply Tier-3 read/write via their group_cr_* chain, so read is doubly preserved.
• spp.cycle / spp.cycle.membership / spp.program.membership read for Program Viewer comes from
  group_programs_viewer, independent of the registry group — unaffected.
• This mirrors the existing Program Cycle Approver precedent, which already uses Tier-3 for exactly
  this reason.

Migration: user_roles.xml is noupdate="1" and the roles ship in the 2026.07 release, so a
plain upgrade would keep the old link. Added post-migration.py for each module
(spp_programs/migrations/19.0.2.2.2, spp_change_request_v2/migrations/19.0.3.0.3) that unlinks the
viewer group, links the read group, and re-materializes already-assigned users' group membership via
res.users.role.action_update_users().

Tests

Test-first (red → green). New tests in each module assert that each role, once assigned to a fresh user
and synced, does not carry group_registry_viewer (would fail before the fix) but does keep
group_registry_read and can functionally read a registrant's res.partner/spp.registry.id/
spp.phone.number (and Program Viewer keeps group_programs_viewer).

./spp t spp_programs → 0 failed of 680; ./spp t spp_change_request_v2 → 0 failed of 336.
No existing tests removed or modified.

Scope / notes

• Not touched: Program Manager / Program Validator (higher-privilege, plausibly use the Registry
  app), Cycle Approver (already Tier-3).
• True per-program registry scoping (limiting registrant read to a user's own programs) would be a
  new cross-cutting feature, not a security patch — noted as a separate design question, not included.
• Version collisions (contended modules): spp_programs .2.2 dodges security(programs): enforce system-admin authorization on Force Unlock #336's .2.1;
  spp_change_request_v2 .0.3 dodges security(cr): route and apply the same single field for dynamic approvals #264 .0.1 / security(cr): add record rules to CR detail models (ownership + area) #261 .0.2. Whoever merges among {security(cr): add record rules to CR detail models (ownership + area) #261, security(cr): route and apply the same single field for dynamic approvals #264,
  security(programs): enforce system-admin authorization on Force Unlock #336, this} later re-conflicts on manifest/HISTORY/README (trivial re-merge). No logic conflict.
• README.rst / static/description/index.html for both modules to be regenerated from CI's pinned generator.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.72%. Comparing base (208d975) to head (f228b96).

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #353      +/-   ##
==========================================
+ Coverage   70.17%   71.72%   +1.54%     
==========================================
  Files         205      282      +77     
  Lines       17751    20577    +2826     
==========================================
+ Hits        12457    14759    +2302     
- Misses       5294     5818     +524     

Flag	Coverage Δ
spp_api_v2_change_request	66.53% <ø> (ø)
spp_programs	65.30% <ø> (+0.02%)	⬆️
spp_security	69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 79 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]

Staff-review residual filed as follow-up: #355 — global_role_program_validator still carries Tier-2 group_registry_viewer (Registry Search menu). Left out of this PR's scope (it holds registry write, so the menu is more defensible); tracked for consistency with Cycle Approver and the roles fixed here.