fusion_claims: ADP workflow recovery actions + email gap fixes

Workflow (from the FigJam ADP board):
- 9 new ADP action methods to wire up the orphan states that the board
  showed had no entry or no exit path: put_on_hold, withdraw, mark_denied,
  mark_rejected, mark_needs_correction, cancel, reopen_cancelled,
  reopen_expired, resubmit_from_denied.
- 12-month auto-expire cron (_cron_adp_expire_approved) configurable via
  fusion_claims.adp_approval_expiry_months, runs daily at 03:00.
- 3 new recovery buttons in the ADP form view (Reopen cancelled, Reopen
  expired, Resubmit from denied) in both the primary status bar and the
  secondary details panel.

Email (from the 2026-04 email audit):
- 6 new ADP stage email methods via a shared _adp_send_stage_email helper:
  assessment_scheduled, assessment_completed, application_received, accepted,
  cancelled, expired. Each has a matching dispatch entry in write().
- _send_rejection_email now includes the client (was authorizer-only).
- _send_accepted_email excludes the authorizer per the new rule: "Accepted"
  is a passive intermediate state with no authorizer action required.
- _send_ready_for_delivery_email excludes the authorizer: operational
  scheduling, not delivery confirmation. Authorizers are notified at
  case_closed when the product is actually delivered.
- action_adp_put_on_hold and action_adp_withdraw now fire their matching
  email methods so direct action-method calls get the same notifications
  as the status_change_reason_wizard path.

Authorizer notification rule (locked in for this update):
  Send to authorizer ONLY for initial involvement (assessment/submit/
  resubmit), delivery confirmation (case_closed), and problem states
  (rejected, denied, needs_correction, withdrawn, on_hold, cancelled,
  expired). Skip for billing, payment, ready_delivery scheduling, and
  passive intermediates (accepted).

Scope: ADP + ADP/ODSP only. MOD workflow emails reverted and deferred
to a separate update.

Deployed to odoo-westin (westin-v19) and odoo-mobility (mobility).
Pre-existing stock_route_warehouse FK orphans on mobility worked around
by verifying fusion_claims transaction committed before container restart.
This commit is contained in:
gsinghpal
2026-04-09 06:06:33 -04:00
parent d60a75a391
commit 8b2cbd9085
5 changed files with 548 additions and 10 deletions

View File

@@ -133,6 +133,14 @@
<field name="value">10</field>
</record>
<!-- ADP funding window: approved applications auto-expire after N months
if not progressed to ready_delivery. ADP doesn't actively notify of
expiry — we trust this window to reflect reality. -->
<record id="config_adp_approval_expiry_months" model="ir.config_parameter">
<field name="key">fusion_claims.adp_approval_expiry_months</field>
<field name="value">12</field>
</record>
<!-- ODSP Settings -->
<record id="config_sa_mobility_email" model="ir.config_parameter">
<field name="key">fusion_claims.sa_mobility_email</field>

View File

@@ -136,5 +136,21 @@
<field name="nextcall" eval="DateTime.now().replace(hour=2, minute=0, second=0)"/>
</record>
<!-- Cron Job: ADP 12-month auto-expire for approved applications.
Approved / approved_deduction orders past the configured funding
window (fusion_claims.adp_approval_expiry_months, default 12 months)
are auto-transitioned to 'expired'. Users can reopen via the
"Reopen Expired" button on the order form. -->
<record id="ir_cron_adp_expire_approved" model="ir.cron">
<field name="name">Fusion Claims: ADP Expire Approved Applications</field>
<field name="model_id" ref="sale.model_sale_order"/>
<field name="state">code</field>
<field name="code">model._cron_adp_expire_approved()</field>
<field name="interval_number">1</field>
<field name="interval_type">days</field>
<field name="active">True</field>
<field name="nextcall" eval="DateTime.now().replace(hour=3, minute=0, second=0)"/>
</record>
</data>
</odoo>