security(cr): validate program access on assign-program detail

[gonzalesedwin1123]

Summary

The spp_cr_type_assign_program apply strategy validated a selected program's
existence, state, target type, and uniqueness — but not the user's access
to the program or its company. The detail's program_id domain only
constrains the UI, so an authenticated CR user with detail write access could
submit a raw ORM/RPC write({'program_id': <arbitrary id>}). On apply, core CR
code runs the strategy on self.sudo() (spp.change.request._do_apply), so
program record rules and multi-company scope were bypassed during validation and
membership creation — assigning the registrant to a hidden/cross-company
program — and preview generation leaked that program's display name through the
same sudo path.

Fix

Add @api.constrains('program_id') to spp.cr.detail.assign_program that, in
the writing user's own context, rejects a program they cannot access:

• visibility — a search() must return the program (enforces any record
  rule on spp.program, and rejects a stale/deleted id);
• multi-company scope — the program's company_id must be within
  self.env.companies. This explicit check is load-bearing, not just
  defense-in-depth: verified by experiment that the global multi-company
  ir.rule on spp.program is not applied to the search in this
  write/constraint context, so search alone would let a cross-company program
  through.

This guards the only sender-reachable input path to program_id; the sudo
apply/preview then only ever consume an already-validated, accessible program.
The apply strategy is annotated to make explicit that access is enforced at
detail-write time, so any future code that sets program_id under sudo must
perform its own access check.

Design decision (confirmed with owner)

Defense in depth: (1) an @api.constrains blocks storing an inaccessible
program_id at the source (write-time, in the user's own context), and (2) the
sudo apply strategy re-asserts program access at the sink, bound to the change
request requester's company scope, before creating the membership.

Correction (2026-08-14): an earlier revision claimed the module is
"unreleased so no pre-existing poisoned records exist" and shipped the
constraint alone. That premise was false — the vulnerable module (v1.0.1,
no constraint) ships in released tags 2026.07 and 2026.08. Because
@api.constrains fires only on write, a program_id written before the
constraint existed is never re-validated, and the sudo apply would trust it.
The apply-time sink re-check (2) closes that residual permanently, and also
covers any future path that sets program_id under sudo without triggering
constraints (import, prefill). No schema migration is required (constraint +
runtime check only); a poisoned pre-existing record simply fails at apply.

Testing

• ./spp t spp_cr_type_assign_program → 26 passed, 0 failed, 0 errors (19
  existing + 4 new), run as a non-admin group_cr_user.
• New tests: a company-A CR user is rejected when writing, and when creating, a
  detail pointing at a company-B program; is allowed to select a company-A
  program; and is allowed to select a company-shared (company_id = False)
  program.

Staff review

Two independent adversarial staff reviews were run. Verdict: ship-with-nits, no
open security hole. Findings addressed in-branch:

• Corrected the constraint's rationale (the company check is load-bearing —
  proven by removing it and watching the reject tests fail).
• Documented in the apply strategy that access is enforced at write time.
• Made the tests robust to in-flight security(cr): add record rules to CR detail models (ownership + area) #261's detail-ownership rule (use the CR
  user's own partner as registrant) and added the shared-program allow case.

Consciously left (low, non-security): an archived program is reported as "no
access" rather than "archived" (apply re-validates state regardless); and a
user lacking any programs-read group gets AccessError rather than the friendly
ValidationError (pre-existing — the feature already requires a programs group).

Notes for reviewers

• Related in-flight PR security(cr): add record rules to CR detail models (ownership + area) #261 (cr-detail-record-rules) also touches this
  module — it adds parent-CR-ownership/area record rules to the detail
  (which detail records you may write). This PR is complementary: it governs
  which program you may target on a detail you legitimately own. Both bump
  the manifest/HISTORY/README, so a version/changelog collision is expected;
  this PR uses 19.0.1.0.3 (higher than both the 19.0 base 19.0.1.0.1 and
  security(cr): add record rules to CR detail models (ownership + area) #261's bump), so whichever merges second needs a trivial re-merge.
• No schema migration: constraint + apply-time check only. NOTE the module IS in released tags (2026.07/2026.08); pre-existing out-of-scope program_id records are caught at apply by the sink re-check rather than by a data migration.
• README generated files are applied from CI's pinned oca-gen verbatim.

Draft: awaiting human security review before undraft/merge.

Merge order (CR security cluster)

Per the cross-PR interaction analysis (2026-07-24, internal/plans/security-prs-interaction-analysis.md), hard order: #264 → #261 → #338 (this PR) → #343.

• Merge only after security(cr): add record rules to CR detail models (ownership + area) #261. The post-security(cr): add record rules to CR detail models (ownership + area) #261 rebase of this branch MUST include a fixture fix to security(cr): add record rules to CR detail models (ownership + area) #261's test file: grant spp_programs.group_programs_viewer to user_a, user_b, and validator in spp_cr_type_assign_program/tests/test_detail_security.py. Reason: this PR's _check_program_access constraint runs a spp.program search() in the writing user's context, and security(cr): add record rules to CR detail models (ownership + area) #261's fixture users hold only group_cr_user, which grants no spp.program read ACL — without the fix, 4 of 5 tests in that file fail on the combined tree. This order makes the failure (and the fix) surface in this PR's own CI.
• Related follow-up filed: security(spp_cr_type_assign_program): program_id not frozen post-submit — applied program can differ from the approved one [Severity: Medium] #347 (program_id remains repointable post-submit; approval-fidelity gap, fix via security(cr): route and apply the same single field for dynamic approvals #264's _protected_content_fields).

[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

❌ Patch coverage is 95.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 70.21%. Comparing base (208d975) to head (ee9842f).
⚠️ Report is 16 commits behind head on 19.0-staging-sec-batch2.

Files with missing lines	Patch %	Lines
...p_cr_type_assign_program/details/assign_program.py	90.00%	1 Missing ⚠️

Additional details and impacted files

@@                     Coverage Diff                     @@
##           19.0-staging-sec-batch2     #338      +/-   ##
===========================================================
+ Coverage                    70.17%   70.21%   +0.03%     
===========================================================
  Files                          205      205              
  Lines                        17751    17775      +24     
===========================================================
+ Hits                         12457    12480      +23     
- Misses                        5294     5295       +1     

Flag	Coverage Δ
spp_base_common	91.07% <ø> (ø)
spp_cr_type_assign_program	92.50% <95.00%> (+0.42%)	⬆️
spp_programs	65.27% <ø> (ø)
spp_registry	87.22% <ø> (+0.07%)	⬆️
spp_security	69.56% <ø> (ø)

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

Files with missing lines	Coverage Δ
...r_type_assign_program/strategies/assign_program.py	94.82% <100.00%> (+1.07%)	⬆️
...p_cr_type_assign_program/details/assign_program.py	86.84% <90.00%> (+0.63%)	⬆️

... and 1 file 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]

Follow-up filed: #347 — this PR guarantees the target program is accessible, but program_id remains repointable post-submit (approval-fidelity gap); fix is an assign-program override of #264's _protected_content_fields.