User reported two UX problems after the Enterprise uninstall:
1. Each Fusion sub-module showed up as its own standalone app in the
launcher (Bank Reconciliation, Financial Reports, Asset Management,
Customer Follow-ups, Fusion AI). Should look like ONE Accounting app.
2. Clicking the 'Fusion Accounting' app still opened the migration
wizard even though Enterprise had been uninstalled and there was
nothing to migrate.
Fix:
- Move all Fusion sub-module roots under the Community account.menu_finance
hierarchy:
* Bank Reconciliation \u2192 Accounting > Bank Reconciliation
* Asset Management \u2192 Accounting > Asset Management
* Financial Reports \u2192 Reporting > Financial Reports
* Follow-ups \u2192 Customers > Follow-ups
* Fusion AI \u2192 Configuration > Fusion AI
* Migrate from Ent. \u2192 Configuration > Migrate from Enterprise
- Rename Community's 'Invoicing' top-level menu to 'Accounting' (what
Enterprise's accountant module did). Set the Fusion icon on it. This
rename lives in the meta-module so it only fires when the full suite
is installed.
- Add second computed group 'group_fusion_show_when_enterprise_present'
(inverse of the existing 'absent' group). Migration menus are gated
by this group, so they auto-hide once Enterprise is uninstalled.
- _fusion_recompute_coexistence_group now maintains both groups in lockstep.
- Meta-module now also depends on l10n_ca, hr_payroll, ocr, documents
(the Phase 6/7 sub-modules) for one-click full-suite install.
- Fusion AI menu's old parent ('accountant.menu_accounting') was deleted
with the Enterprise uninstall \u2014 reparented under Configuration.
Result: single 'Accounting' top-level menu containing the standard
V19 Community structure (Dashboard / Customers / Vendors / Accounting /
Reporting / Configuration), with all Fusion features slotted into the
appropriate sub-section. Verified live on westin-v19: 6 separate
Fusion top-level menus collapsed to 1; coexistence groups recomputed
(absent=10 users, present=0 users); 604/604 tests pass.
Version bump: all touched modules \u2192 19.0.1.1.0.
Made-with: Cursor
- fusion.followup.cron AbstractModel with two handlers
- cron_fusion_followup_daily_scan: walks every overdue partner and
delegates to engine.send_followup_email
- cron_fusion_followup_risk_refresh: weekly refresh of
fusion_followup_risk_score / risk_band on res.partner
- V19 ir.cron records (no numbercall field)
- 2 smoke tests added (80 total)
Made-with: Cursor
- Switch FUSION_MODEL to fusion.followup.engine so adapter mode
selection matches the new module
- Add list_overdue() with fusion/enterprise/community variants
- Re-route send_followup_via_fusion to engine.send_followup_email
- 4 new TransactionCase tests (73 total)
Existing aging / overdue_invoices adapter methods continue to fall
back to the community implementation.
Made-with: Cursor
End-to-end flows over a real posted receivable line: aging discovery,
level resolution, send-with-cache reuse, pause+force override, and
audit history growth. Adds ignore_pause kwarg to compute_followup_level
so force=True in send_followup_email reaches level resolution.
Made-with: Cursor
The orchestrator AbstractModel for follow-up lifecycle.
get_overdue_for_partner, compute_followup_level, send_followup_email,
escalate_to_next_level, pause_followup, reset_followup, snapshot_followup_history.
All controllers, AI tools, wizards, cron must route through these
methods; no direct ORM writes to fusion.followup.run from anywhere else.
Made-with: Cursor
