spp_alerts: Alerts Manager can edit/delete/disable other users' (incl. admins') alert rules (no owner-scoping) — integrity/availability [Low-Medium]

[gonzalesedwin1123]

Summary

group_alerts_manager has model-wide write and unlink on spp.alert.rule (spp_alerts/security/ir.model.access.csv: access_spp_alert_rule_alerts_manager = read/write/create/unlink all 1), and there is no record rule confining a manager to the rules they own (spp_alerts/security/rules.xml only has a multi-company rule). So any Alerts Manager can edit, disable (active=False), or delete another user's — including an administrator's — alert rule.

Why this is (now) an integrity/availability issue, not a data leak

PR #364 closed the data-leak dimension: a rule's monitored search is evaluated as the user who last configured its targeting (eval_as_user_id), and any targeting edit re-binds that identity to the editor. So a manager editing an admin-authored rule de-escalates it — they can no longer make it surface records they can't see.

What remains is a cross-owner integrity/availability surface that PR #364 deliberately did not change (it would alter the delegation model):

• A manager can delete or archive an admin-configured monitoring rule, silently stopping alerts the organization relies on (e.g. compliance/expiry monitoring) — no audit gate beyond the standard chatter.
• A manager can rewrite an admin's rule (which de-escalates evaluation, but still lets them repurpose or neuter it).

This is inherent to the current "Manager = full alert rule configuration" delegation (group_alerts_manager is a delegated role, not base.group_system).

Options (needs a design decision)

• A — Owner-scoped write/unlink record rule. Add an ir.rule on spp.alert.rule limiting group_alerts_manager write/unlink to create_uid = user. Caveat: spp_security.group_spp_admin implies group_alerts_manager, so a per-group rule would also confine transitively-manager admins to their own rules — the rule needs to exempt base.group_system / spp_admin (e.g. via a companion permissive rule) so real admins retain full control.
• B — Keep full edit, gate destructive ops. Leave write model-wide (evaluation is already de-escalated by fix(spp_alerts): evaluate alert rules as their owner, not the elevated cron #364) but restrict unlink/active=False on rules the caller doesn't own, or require an approval/confirmation for deleting an admin-owned rule.
• C — Accept as-is. Treat cross-owner rule management as intended for the Manager role and document it.

Notes

• Discovered during the staff review of PR fix(spp_alerts): evaluate alert rules as their owner, not the elevated cron #364 (alert-rule safe_eval / elevated-cron leak). Back-linked there.
• No data-confidentiality impact after fix(spp_alerts): evaluate alert rules as their owner, not the elevated cron #364 — this is integrity/availability of the monitoring configuration only.
• Severity: Low–Medium (requires an authenticated, semi-trusted Alerts Manager; impact is loss/alteration of monitoring, not disclosure).