Repro: open the engagement wizard on a ticket, write findings, click
'Generate Summary from Findings'. Notification: "Ticket N no longer
exists" and the whole dialog closes — even though the ticket clearly
exists in the DB.
Root cause was two compounding bugs:
1. action_generate_summary returned an act_window dict with
res_id=self.id to "stay open after writing the summary field". The
web client honoured that by opening a NEW act_window — and the new
action's context inherited active_id=<wizard_id> (because that's
the res_id of the action being opened). Wizard ids are not ticket
ids, but our default_get didn't know the difference.
2. default_get read ctx.get('active_id') unconditionally, without
first checking ctx.get('active_model') == 'helpdesk.ticket'. So
when active_id pointed at the wizard's own id, default_get fed
that to _default_get_single, which raised "Ticket <wizard_id> no
longer exists" — and the user saw a confusing error about a
ticket that obviously DID exist (just not with that id).
Two fixes:
(a) action_generate_summary + action_generate_all_summaries now
return True. The form field write is visible to the client via
the call response; the wizard re-renders with the new
ai_summary populated. No spurious navigation, no context
pollution.
(b) default_get only consults active_id / active_ids when
active_model is helpdesk.ticket. Explicit
default_ticket_id[s] context keys still take precedence and
aren't gated by active_model (they're the caller's strong
signal).
Verified live: opening the wizard with active_id=99999 and NO
active_model no longer raises 'Ticket 99999 no longer exists' —
just creates the wizard cleanly. The normal flow (default_ticket_id
+ active_model='helpdesk.ticket') still works as before.
Bumps fusion_helpdesk_central to 19.0.2.3.3.
46 lines
1.7 KiB
Python
46 lines
1.7 KiB
Python
# -*- coding: utf-8 -*-
|
|
# Copyright 2026 Nexa Systems Inc.
|
|
# License OPL-1
|
|
{
|
|
'name': 'Fusion Helpdesk Central — Client API Keys',
|
|
'version': '19.0.2.3.3',
|
|
'category': 'Productivity',
|
|
'summary': 'Admin UI on the central Odoo for issuing per-client API '
|
|
'keys used by fusion_helpdesk client deployments.',
|
|
'description': """
|
|
Fusion Helpdesk Central
|
|
=======================
|
|
Companion to `fusion_helpdesk`. Install on the central Odoo (the one
|
|
running the Helpdesk app) to manage **per-client API keys** instead of
|
|
shipping a shared bot password to every client deployment.
|
|
|
|
Each row in *Helpdesk → Configuration → Client API Keys* maps a client
|
|
label (e.g. ENTECH, MOBILITY) to a real `res.users.apikeys` row on the
|
|
shared bot user. The plaintext key is shown ONCE on creation; revoke
|
|
in one click if a deployment is compromised.
|
|
|
|
Depends only on `helpdesk`. No client-side install needed.
|
|
""",
|
|
'author': 'Nexa Systems Inc.',
|
|
'website': 'https://www.nexasystems.ca',
|
|
'license': 'OPL-1',
|
|
'depends': ['helpdesk'],
|
|
'data': [
|
|
'security/ir.model.access.csv',
|
|
'data/ir_config_parameter_data.xml',
|
|
'data/mail_template_ack.xml',
|
|
'data/mail_template_engagement.xml',
|
|
'data/helpdesk_tag_critical.xml',
|
|
'data/ir_cron_engagement_reminder.xml',
|
|
'views/fusion_helpdesk_client_key_views.xml',
|
|
'views/helpdesk_ticket_views.xml',
|
|
'views/engagement_wizard_views.xml',
|
|
'views/engagement_reporting_views.xml',
|
|
'views/portal_templates.xml',
|
|
'views/res_config_settings_views.xml',
|
|
],
|
|
'installable': True,
|
|
'auto_install': False,
|
|
'application': False,
|
|
}
|