d60a75a391
Two daily MOD crons were fighting each other. _cron_mod_schedule_followups created a mail.activity on every MOD order in quote_submitted/awaiting_funding; _cron_mod_escalate_followups unconditionally deleted the activity after sending its one-time reminder email. The activity was recreated every day in a tight loop with no per-period cap — a legitimate 2-4 month wait for a MOD funding decision would generate dozens of activity churn events and a bulk email burst the first time the escalate cron ran against a backlog. Fix: - New fields x_fc_mod_followup_month_count / _month_start / _cap_notified (copy=False) track a rolling window per order. - New config params mod_followup_max_per_month (default 2), mod_followup_window_days (30), mod_followup_max_per_cron_run (10). - _send_mod_followup_email resets the window after 30 days, refuses to send past the cap, and posts a one-shot chatter note explaining why. - _cron_mod_schedule_followups no longer recreates the activity when the cap has been hit and stops daily-bumping x_fc_mod_next_followup_date. - _cron_mod_escalate_followups processes oldest-deadline-first with a per-run throttle, only unlinks the activity on a successful send so humans can still action capped cases manually. - write() resets the rolling counters on any real MOD status change. Deployed to fusion_claims v19.0.8.0.1 on odoo-westin (westin-v19, 36 affected orders) and odoo-mobility (mobility, 2 affected orders).