32c7026558
The owner only saw the AI summary, which was a paraphrase of the user
report — they couldn't see the actual request OR what we said back.
Restructure the engagement email into three sections so the owner can
read the conversation and not just the AI's take:
1. Original Request (from the reporter) — ticket.description, no
longer buried in a <details> collapsible at the bottom
2. Our Reply — the wizard's "Your Findings" text, now persisted on
the ticket so the email template can render it directly. This is
the engineer's analysis / response to the request.
3. Summary for the Decision — the AI-generated brief
Approve / Reject buttons stay below all three. Bulk email mirrors the
same per-card structure.
New ticket field x_fc_engagement_findings (Text, copy=False) stores
the findings at send-time so they survive as audit history. Wizard's
_action_send_single / _action_send_bulk pass findings into
_fc_reset_engagement; bulk uses per-line findings + per-line summary.
Mail templates are in <data noupdate="1"> so a plain -u doesn't
re-import them. Pre-migration in migrations/19.0.2.4.0/pre-migration.py
deletes the existing template records + ir_model_data so the upgrade's
data load re-creates them with the new body_html. Pre- (not post-)
because data load happens between the two phases.
Smoke-tested live on nexa: rendered template HTML contains all three
section headers at the expected positions with their expected content
markers (ORIGINAL FROM RIYA in Original Request, REPLY-FROM-GURPREET
in Our Reply, the summary text in Summary for the Decision).
Bumps fusion_helpdesk_central to 19.0.2.4.0.
69 lines
2.2 KiB
Python
69 lines
2.2 KiB
Python
# -*- coding: utf-8 -*-
|
|
# Copyright 2026 Nexa Systems Inc.
|
|
# License OPL-1
|
|
"""Force re-import of the engagement mail templates on 19.0.2.4.0.
|
|
|
|
The mail templates ship in `<data noupdate="1">` so support's later
|
|
tweaks (different reply-to, custom signature, etc.) aren't blown away
|
|
by every routine module upgrade. The flip side: a structural change
|
|
to the template body in our own XML is silently skipped — the next
|
|
`-u` reads the new XML but Odoo refuses to overwrite the existing
|
|
row because of the noupdate flag.
|
|
|
|
This release introduces the 3-section email layout (Original Request /
|
|
Our Reply / Summary) and we DELIBERATELY want it to land. So this
|
|
pre-migration deletes the existing template records + their
|
|
ir_model_data anchors BEFORE the upgrade's data load runs. The XML
|
|
import then re-creates them with the new body_html.
|
|
|
|
Pre-migration > post-migration here because data load happens between
|
|
the two. If we deleted in post-migration, the data load would already
|
|
have skipped the update — too late.
|
|
"""
|
|
import logging
|
|
|
|
_logger = logging.getLogger(__name__)
|
|
|
|
|
|
_TEMPLATE_XMLIDS = (
|
|
'mail_template_engagement',
|
|
'mail_template_engagement_bulk',
|
|
)
|
|
|
|
|
|
def migrate(cr, version):
|
|
cr.execute(
|
|
"""
|
|
SELECT name, res_id FROM ir_model_data
|
|
WHERE module = 'fusion_helpdesk_central'
|
|
AND name IN %s
|
|
""",
|
|
(_TEMPLATE_XMLIDS,),
|
|
)
|
|
rows = cr.fetchall()
|
|
if not rows:
|
|
_logger.info(
|
|
'fusion_helpdesk_central 19.0.2.4.0 pre-migration: no '
|
|
'existing engagement templates to delete; nothing to do.'
|
|
)
|
|
return
|
|
template_ids = [r[1] for r in rows]
|
|
cr.execute(
|
|
"DELETE FROM mail_template WHERE id IN %s",
|
|
(tuple(template_ids),),
|
|
)
|
|
cr.execute(
|
|
"""
|
|
DELETE FROM ir_model_data
|
|
WHERE module = 'fusion_helpdesk_central'
|
|
AND name IN %s
|
|
""",
|
|
(_TEMPLATE_XMLIDS,),
|
|
)
|
|
_logger.info(
|
|
'fusion_helpdesk_central 19.0.2.4.0 pre-migration: dropped %s '
|
|
'engagement mail template(s) so the upgrade re-imports them '
|
|
'with the new 3-section layout: %s',
|
|
len(template_ids), ', '.join(r[0] for r in rows),
|
|
)
|