feat(fusion_helpdesk): owner-approval engagement flow + AI summary + reporting
Ships the design spec at docs/superpowers/specs/2026-05-27-owner-approval-flow-design.md. What's new on central (fusion_helpdesk_central 19.0.1.2.0 -> 19.0.2.0.0): - Engagement model: 8 new fields on helpdesk.ticket (state, snapshotted owner email/name, single-use UUID4 token, sent/reminded/decided timestamps, AI summary, stored-computed turnaround hours). - Wizard: single + bulk modes on one fusion.helpdesk.engagement.wizard TransientModel with a child wizard.line for per-ticket bulk summaries. default_get pulls the OpenAI summary on open; AI fan-out for bulk is parallel via ThreadPoolExecutor (max 5 workers, 30s overall cap). - OpenAI client in utils.py — stdlib urllib, 15s per-call timeout, every failure collapses to '' so the wizard's manual-summary fallback fires. - Public portal: /fusion_helpdesk/engagement/<token>/<decision> GET + POST, four branded standalone QWeb pages (confirm/done/invalid/error). Token is single-use, cleared on confirm. Decision posts a public comment attributed to the resolved owner partner; chatter propagates to the employee's My Tickets thread per the "fully visible" UX choice. - Mail templates (single + bulk) with magic-link buttons. Bulk template renders one card per ticket, each with its own approve/reject URL. - Reminder cron: daily, single-shot per engagement, configurable via fusion_helpdesk_central.engagement_reminder_days ICP (default 3, 0 disables). - Reporting dashboard: pivot/graph/list/kanban over helpdesk.ticket filtered to engaged ones, with avg-turnaround measure. Menu lives under Helpdesk > Reporting > Owner Engagements. - Client_key extended with owner_email/owner_name fields; ticket.create upserts them from the client-side piggyback (no new sync endpoint). - 100% coverage on utils + integration tests on wizard, controllers, re-engagement, cron, computed turnaround. OpenAI mocked in CI. What's new on client (fusion_helpdesk 19.0.1.7.1 -> 19.0.2.0.0): - Two new ICP settings: fusion_helpdesk.owner_email / .owner_name with a new "Owner Approval" block in Settings > Fusion Helpdesk. - controllers/main.py::submit piggybacks both keys on every ticket payload so central keeps client_key.owner_email/name fresh automatically. Verified live end-to-end on entech -> nexa: payload upsert, wizard with mocked AI, action_send, portal GET/POST/GET-again cycle, second click hits the friendly invalid-token page. Token entropy = 122 bits (UUID4).
This commit is contained in:
@@ -27,8 +27,100 @@
|
||||
<field name="x_fc_client_label"/>
|
||||
<filter string="Client Deployment" name="group_client_label"
|
||||
context="{'group_by': 'x_fc_client_label'}"/>
|
||||
<separator/>
|
||||
<filter string="Awaiting Owner Approval" name="fhc_pending_engagement"
|
||||
domain="[('x_fc_engagement_state', '=', 'pending')]"/>
|
||||
<filter string="Owner Approved" name="fhc_approved_engagement"
|
||||
domain="[('x_fc_engagement_state', '=', 'approved')]"/>
|
||||
<filter string="Owner Rejected" name="fhc_rejected_engagement"
|
||||
domain="[('x_fc_engagement_state', '=', 'rejected')]"/>
|
||||
</xpath>
|
||||
</field>
|
||||
</record>
|
||||
|
||||
<!--
|
||||
Inherited ticket form. Adds:
|
||||
* Header button "Request Owner Approval" (form-button entry into
|
||||
the wizard). Disabled when there's no client_label OR no owner
|
||||
contact on the client_key — see the action_open_engagement_wizard
|
||||
method which raises a UserError with the same explanation.
|
||||
* State pill in the title row showing pending / approved / rejected.
|
||||
* Collapsible "Owner Engagement" group with the audit fields.
|
||||
Inherited views in Odoo 19 cannot carry `groups`/`group_ids` on the
|
||||
record (raises ParseError); per-node `groups=` attributes are fine.
|
||||
-->
|
||||
<record id="fhc_ticket_form_engagement" model="ir.ui.view">
|
||||
<field name="name">fhc.helpdesk.ticket.form.engagement</field>
|
||||
<field name="model">helpdesk.ticket</field>
|
||||
<field name="inherit_id" ref="helpdesk.helpdesk_ticket_view_form"/>
|
||||
<field name="arch" type="xml">
|
||||
|
||||
<!-- Header button + state badge. Placed at the top of the
|
||||
header so it's the first thing support sees. -->
|
||||
<xpath expr="//header" position="inside">
|
||||
<button name="action_open_engagement_wizard"
|
||||
type="object"
|
||||
string="Request Owner Approval"
|
||||
class="oe_highlight"
|
||||
invisible="not x_fc_client_label or x_fc_engagement_state == 'pending'"
|
||||
groups="base.group_user"/>
|
||||
<button name="action_open_engagement_wizard"
|
||||
type="object"
|
||||
string="Re-engage Owner"
|
||||
invisible="x_fc_engagement_state != 'pending'"
|
||||
groups="base.group_user"/>
|
||||
<field name="x_fc_engagement_state" widget="statusbar"
|
||||
invisible="x_fc_engagement_state == 'none'"
|
||||
statusbar_visible="pending,approved,rejected"/>
|
||||
</xpath>
|
||||
|
||||
<!-- Collapsible Owner Engagement page on the notebook. -->
|
||||
<xpath expr="//notebook" position="inside">
|
||||
<page string="Owner Engagement"
|
||||
name="fhc_engagement_page"
|
||||
invisible="x_fc_engagement_state == 'none'">
|
||||
<group>
|
||||
<group>
|
||||
<field name="x_fc_engagement_state" readonly="1"/>
|
||||
<field name="x_fc_engagement_name" readonly="1"/>
|
||||
<field name="x_fc_engagement_email" readonly="1" widget="email"/>
|
||||
</group>
|
||||
<group>
|
||||
<field name="x_fc_engagement_sent_at" readonly="1"/>
|
||||
<field name="x_fc_engagement_reminded_at" readonly="1"/>
|
||||
<field name="x_fc_engagement_decided_at" readonly="1"/>
|
||||
<field name="x_fc_engagement_turnaround_hours" readonly="1"/>
|
||||
</group>
|
||||
</group>
|
||||
<separator string="AI Summary (snapshotted at engagement)"/>
|
||||
<field name="x_fc_ai_summary" readonly="1" nolabel="1"/>
|
||||
</page>
|
||||
</xpath>
|
||||
|
||||
</field>
|
||||
</record>
|
||||
|
||||
<!--
|
||||
Kanban dot on the main Helpdesk kanban deferred — the underlying
|
||||
view's structure varies between Helpdesk versions and reaching into
|
||||
it with xpath is fragile. The Reporting → Owner Engagements kanban
|
||||
(grouped by state) gives the same at-a-glance signal until we have
|
||||
a stable hook in helpdesk's main kanban.
|
||||
-->
|
||||
|
||||
<!--
|
||||
Server action — bulk "Request Owner Approval" available from the
|
||||
helpdesk.ticket list view. Validation happens in the wizard's
|
||||
default_get; the server action just opens the wizard with the
|
||||
selection in context.
|
||||
-->
|
||||
<record id="action_engagement_bulk" model="ir.actions.server">
|
||||
<field name="name">Request Owner Approval (Bulk)</field>
|
||||
<field name="model_id" ref="helpdesk.model_helpdesk_ticket"/>
|
||||
<field name="binding_model_id" ref="helpdesk.model_helpdesk_ticket"/>
|
||||
<field name="binding_view_types">list,kanban</field>
|
||||
<field name="state">code</field>
|
||||
<field name="code">action = model.action_open_engagement_wizard_bulk()</field>
|
||||
</record>
|
||||
|
||||
</odoo>
|
||||
|
||||
Reference in New Issue
Block a user