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:
@@ -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>
|
||||
|
||||
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user