fusion_accounting_reports — Upgrade Notes

Odoo Version Anchor

This module targets Odoo 19.0 (community-base).

Reference snapshot of Enterprise code mirrored from:

account_reports (Odoo 19.0.x)
Source: /Users/gurpreet/Github/RePackaged-Odoo/accounting/account_reports/

Cross-Version Diff Strategy

When a new Odoo version ships:

Run check_odoo_diff.sh (in repo root) against the new Enterprise version
Note any breaking changes in account.move.line / account.account API surfaces relied on by services/totaling.py and services/drill_down_resolver.py
For mirrored OWL components, diff Enterprise's new versions against ours and port material changes (signature renames, new behaviour we want to inherit)
Re-run the full test suite + tour tests + benchmarks against the new Odoo version
Update this file with the new version anchor + any deviations

V19 Migration Notes (already applied — Phase 1 lessons)

These were the bite-points from Phase 1 (fusion_accounting_bank_rec); we preempted them in Phase 2 from day one:

_sql_constraints → models.Constraint (used in fusion.report, fusion.report.commentary, fusion.report.anomaly)
@api.depends('id') → removed everywhere; computed fields depend on real field names instead
@route(type='json') → type='jsonrpc' (all 8 endpoints)
numbercall field on ir.cron → omitted (removed in V19)
res.groups.users → user_ids
ir.ui.menu.groups_id → group_ids (used in views/menu_views.xml and the two wizard view files for the coexistence-group filter)

Engine API Stability

The 5 public engine methods (compute_pnl, compute_balance_sheet, compute_trial_balance, compute_gl, drill_down) are the public contract. Their signatures are keyword-only after the first positional argument and will be treated as semver-stable across patch releases. Breaking changes will bump the minor version (e.g. 19.0.2.x.y).

Phase 2 → Phase 2.5 Migration

If we ship Phase 2.5 (line_spec polish, deferred features, header_only flag, prefix overlap fix), changes will go in incremental commits. No DB migration needed — Phase 2 schema is forward-compatible:

fusion.report.line_specs is a JSON column; the migration path is to rewrite specs in place
fusion.account.balance.mv can be dropped/re-created freely
fusion.report.commentary is a cache; safe to truncate on upgrade
fusion.report.anomaly records carry Period as date_from/date_to fields; no schema-level changes anticipated

2.5 KiB Raw Permalink Blame History