security(grm): restrict GRM automation rules to GRM staff (drop portal write/create)

[gonzalesedwin1123]

Problem

spp_grm_cel/security/ir.model.access.csv granted base.group_portal read + write + create
(1,1,1,0) on the global config models spp.grm.routing.rule and spp.grm.escalation.rule,
with no ir.rule record rules scoping them. A low-privileged portal user could therefore
create an always-matching routing or escalation rule via RPC:

• Routing rules run on ticket creation and can write team_id, user_id, severity,
  priority.
• Escalation rules run on stage changes and via the hourly cron over all open tickets
  (executed elevated), and can reassign/escalate, send configured notifications, and create
  cases.

So a single planted rule turns portal access into unauthorized, global GRM workflow
modification and potential mass disruption of grievance handling. Severity: High.

Fix

Reduce the two portal ACL rows to read-only (1,0,0,0), matching the existing
base.group_user rows:

access_spp_grm_routing_rule_portal_user,...,base.group_portal,1,0,0,0
access_spp_grm_escalation_rule_portal_user,...,base.group_portal,1,0,0,0

Rule evaluation runs as the current user (ticket.create() → apply_routing() →
search() on the rule model), so read access must be retained or routing silently stops
applying — exactly why base.group_user also has read-only. Portal users lose the ability to
create or modify global rules; GRM officers/managers retain full management.

Portal ticket submission via the controller is already sudo()d
(spp_grm/controllers/grm_portal.py), so that flow is unaffected either way.

Tests

New spp_grm_cel/tests/test_rule_acl.py:

• portal user is denied create on both rule models (AccessError);
• portal user is denied write on both rule models (AccessError);
• portal user retains read (evaluation still works);
• a GRM manager can still create both rule types.

Written test-first (4 denial tests failed pre-fix — confirming portal could create/write —
then passed after). ./spp test spp_grm_cel → 35 passed, 0 failed; ./spp lint clean.

Out of scope (noted for awareness)

• spp_grm grants portal 1,1,1,0 on spp.grm.ticket itself (portal can create tickets via
  RPC, not only via the sudo controller) — separate question, not changed here.
• apply_escalation writes escalation_count without sudo() (unlike routing's sudo'd
  counter) — a pre-existing inconsistency; escalation triggered by a read-only portal user now
  fails closed (caught/logged), which is the intended behavior.

[gemini-code-assist]

Code Review

This pull request restricts portal users to read-only access for GRM routing and escalation rules by updating the ACL configurations in ir.model.access.csv. It also introduces a comprehensive suite of integration tests in test_rule_acl.py to verify these access control constraints. There are no review comments, and I have no additional feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.27%. Comparing base (f0a58b0) to head (bebd609).
⚠️ Report is 1 commits behind head on 19.0-staging-sec-batch1.

Additional details and impacted files

@@                     Coverage Diff                     @@
##           19.0-staging-sec-batch1     #266      +/-   ##
===========================================================
+ Coverage                    71.25%   71.27%   +0.01%     
===========================================================
  Files                          227      226       -1     
  Lines                        15441    15664     +223     
===========================================================
+ Hits                         11002    11164     +162     
- Misses                        4439     4500      +61     

Flag	Coverage Δ
spp_base_common	91.07% <ø> (ø)
spp_grm_cel	77.23% <100.00%> (?)
spp_oauth	?
spp_programs	65.27% <ø> (ø)
spp_registry	86.94% <ø> (ø)
spp_security	69.56% <ø> (ø)

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

Files with missing lines	Coverage Δ
spp_grm_cel/models/grm_escalation_rule.py	76.76% <100.00%> (ø)

... and 11 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 (post-rebase, head 1c36d437): SHIP-WITH-NITS. Both nits are now addressed in aa06b303:

• Added the missing readme/HISTORY.md fragment for the 19.0.2.0.1 bump. (Note: CI does not catch this class of omission — an absent fragment produces no README drift, so the oca-gen hook has nothing to diff.)
• Sudo'd the escalation_count write to match its routing-rule twin at grm_routing_rule.py:263. Previously a caller without write access failed midway through apply_escalation — after the notification was sent and the case created — rather than failing closed.

Review confirmed: the exposure was real and globally scoped (neither rule model has any ir.rule, so the ACL row was the only boundary); portal grievance submission does not regress (all three controller routes are read/read/sudo-create); the retained portal read is deliberate because apply_routing/apply_escalations search as the current user; tests use a genuine portal user with Odoo 19 group_ids and fail without the fix; no upstream drift re-opened it; no migration needed (ACL rows are noupdate=False); no version collision; independent of #327/#329.

Three follow-ups filed, out of scope here: #379 (rule CEL evaluates as superuser — same shape as #364, lets a GRM officer seize every ticket), #380 (portal has read/write/create on every ticket with no record rule — the ticket-model half of this over-grant), #381 (unguarded RPC-callable rule-engine entry points).

[gemini-code-assist]

Caution

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