Smaller UX simplification on the client side: the owner is already a
contact in entech's address book, so picking one is faster + safer than
re-typing their email and name (and avoids typos creeping into the
approval-email To: header).
What changed:
- Entech settings: drop fhd_owner_email + fhd_owner_name char fields;
add fhd_owner_partner_id Many2one to res.partner exposed in the
same "Owner Approval" block as a single partner selector. Quick-create
+ create-and-edit kept enabled so admins can spin up a new partner
inline if the owner isn't already in the system.
- controllers/main.py::_read_config: derives owner_email + owner_name
from the selected partner via the new _resolve_owner_contact helper.
Missing / dangling partner id → blank email + name → central simply
won't see the keys and the Engage button stays disabled (correct
"not configured" behaviour).
- Nexa side: ZERO changes. Still receives owner_email + owner_name
strings on the ticket payload, still upserts client_key.owner_email/
name. The partner abstraction stops at the entech boundary.
- migrations/19.0.2.1.0/post-migration.py auto-resolves the legacy
fusion_helpdesk.owner_email ICP value to an existing res.partner
(lowest-id match on lowercased email), writes the new
fusion_helpdesk.owner_partner_id key, and deletes the obsolete
owner_email + owner_name ICP rows so a future reader doesn't trip
over stale config.
Verified live on entech: kris@enplating.ca → res.partner #2308 ("Kris
Pathinather"), legacy keys purged, controller._resolve_owner_contact
returns the expected (email, name). The piggyback payload is unchanged
so existing client_key sync continues to work without a central
redeploy.
Bumps fusion_helpdesk to 19.0.2.1.0. fusion_helpdesk_central stays at
19.0.2.0.0 (no central-side changes required).
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).
