[T3314] Donations linked to events silently lose their event association since the analytic multi-plan migration#2112
Conversation
…tic plans account.move.line._compute_event() only checked the generic account_id column, but event analytic accounts live under the dedicated crm_compassion.plan_events analytic plan, whose accounts are stored in that plan's own dynamic x_plan<N>_id column instead. Resolve the correct column via account.analytic.plan._column_name() rather than hardcoding it.
There was a problem hiding this comment.
Code Review
This pull request updates the _compute_event method in account_move_line.py to correctly retrieve event analytic accounts from the custom crm_compassion.plan_events analytic plan column. The review feedback points out two critical issues: a potential traceback during module installation/upgrade if the XML reference is not found, and incorrect compute logic that prevents event_id from being cleared or updated when dependencies change. A simplified and safer implementation is suggested to resolve these issues.
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.
| events_column = self.env.ref("crm_compassion.plan_events")._column_name() | ||
| for line in self: | ||
| if not line.event_id and line.analytic_line_ids.account_id.event_id: | ||
| line.event_id = line.analytic_line_ids.account_id.event_id | ||
| analytic_accounts = line.analytic_line_ids.account_id | ( | ||
| line.analytic_line_ids.mapped(events_column) | ||
| ) | ||
| event = analytic_accounts.mapped("event_id")[:1] | ||
| if not line.event_id and event: | ||
| line.event_id = event | ||
| else: | ||
| line.event_id = line.event_id |
There was a problem hiding this comment.
There are two issues with the current implementation of _compute_event:
- Robustness during installation/upgrade: Calling
self.env.ref("crm_compassion.plan_events")withoutraise_if_not_found=Falsecan cause a traceback during module installation or upgrade if the compute method is triggered before the XML data is loaded into the database. - Correctness of the compute logic: The conditional check
if not line.event_id and event:prevents the field from being updated or cleared if the analytic distribution is changed or removed on an existing line. In Odoo, a compute method should always assign a value to the field for all records inselfto ensure correctness when dependencies change.
We can simplify and fix both issues by retrieving the plan safely and directly assigning the resolved event (or False if none is found) to line.event_id.
plan = self.env.ref("crm_compassion.plan_events", raise_if_not_found=False)
events_column = plan._column_name() if plan else None
for line in self:
analytic_accounts = line.analytic_line_ids.account_id
if events_column:
analytic_accounts |= line.analytic_line_ids.mapped(events_column)
line.event_id = analytic_accounts.mapped("event_id")[:1]There was a problem hiding this comment.
- I think it is optional, not a real bug here. I could take it or leave it.
- This is a pre-existing behavior outside of this PR's scope. I do not know if it wrong or right and it might blast me away for another day as it is a bigger analysis of behavior.
I will not touch it if senior do not tell me to go for it first
T3314 — Donations linked to events silently lose their event association
Found while working T0632.
The whole event-thank-you pipeline couldn't be exercised on real data because
event_idnever resolved onaccount.move.line.Root cause
Migration commit
e43ef938 [MIG] T2713 crm_compassion: migration to 18.0introduced a dedicated analytic plan for events (crm_compassion.plan_events— v14 had no concept of analytic plans, a v17+ Odoo accounting feature), andevent_compassion.py's_get_analytic_vals()assigns every new event's own analytic account to this plan. Butaccount.move.line._compute_event()was carried over from the v14 code unchanged — it only ever reads the genericanalytic_line_ids.account_idfield.Under Odoo 18's multi-plan analytics, each plan stores its account reference in its own dedicated column on
account.analytic.line(x_plan<N>_id, N = that plan's id — resolved dynamically viaaccount.analytic.plan._column_name(),addons/analytic/models/ analytic_plan.py:115-121); the genericaccount_idcolumn is reserved for the root/project plan only. Since every event's own analytic account lives specifically in the "Events" plan,_compute_event()could never find it.This does not fire an error anywhere, just a quietly empty field.
What changed
models/account_move_line.py:_compute_event()now also checks the "Events" plan's dynamic column (resolved via_column_name(), not hardcoded — robust to the plan having a different id in another database), in addition to the genericaccount_id.No backfill migration was added for historical lines affected since the regression window (2026-06-04 onward in this DB) — worth a follow-up if that missing historical data matters.
How to test manually
-u crm_compassion).event.analytic_id).account.move.line.event_id— should now resolve to the event (previously always empty for any event created after 2026-06-04 in this DB, or after whichever date production hit the same migration commit).Video for testing manually for thank you letters
Screencast.From.2026-07-16.09-50-16.mp4