Hello OCA team,
We’re migrating to Odoo 19 and have adapted impersonate_login accordingly. In 18.0 the addon worked fine; in 19.0 we hit a few API changes and addressed them locally.
Root cause observed
- Odoo 19 dropped the extra
raise_on_email kwarg on mail.thread._message_compute_author.
- The lowercased
fields.datetime.now() alias is gone; only fields.Datetime.now() remains.
- Session custom keys in 19 must be accessed via the mapping API (e.g.,
request.session["my_key"] / request.session.get("my_key")), not as attributes.
- On
res.groups XML, the relation field is user_ids (not users).
Working approach we implemented locally
- Updated
mail.thread override signature to def _message_compute_author(self, author_id=None, email_from=None) and adjusted the super() call.
- Replaced
fields.datetime.now() with fields.Datetime.now().
- Switched all usage of
request.session.impersonate_from_uid and similar to mapping-style reads/writes: request.session.get("impersonate_from_uid") and request.session["impersonate_from_uid"] = ....
- Fixed
security/group.xml to use <field name="user_ids" .../>.
- Kept the impersonation flow identical (swap
request.session.uid, recompute session_token via odoo.service.security.compute_session_token, and client reload). This still works in 19.
- UI: since we return an action object directly from RPC (not via
/web/action/load), we wrap the help string with Owl’s markup() in the client so that any HTML help renders like standard actions in 19. We also provide a styled empty-list helper (smiling face + paragraph) for the Switch Login selector.
Key details
- The server-side session change and
session_token recomputation is unchanged and remains necessary in 19.
- Extending
ir.http.session_info() to expose is_impersonate_user and impersonate_from_uid remains the correct pattern.
- Authorship: overrides ensuring chatter clarity and
create_uid/write_uid attribution to the original user during impersonation continue to work in 19 once session keys use the mapping API.
Questions
- Can you confirm these changes align with Odoo 19 best practices for this addon?
- Could you please create/confirm a
19.0 branch for server-auth so we can open a PR for impersonate_login? I currently don’t see a 19.0 branch to target.
Testing
- Installed on a fresh 19.0 DB with
--stop-after-init, verified:
- Switch/Back menu entries visibility
- Session switching + token recompute + client reload
- Chatter shows “Logged in as …” during impersonation
create_uid / write_uid attribution preserved (original impersonating user)
- Logs recorded under Settings → Technical → Impersonated Logs
Happy to push the patch and a concise README note for 19.0 once the target branch is available.
Thanks!
— Milan Topuzov
Hello OCA team,
We’re migrating to Odoo 19 and have adapted
impersonate_loginaccordingly. In 18.0 the addon worked fine; in 19.0 we hit a few API changes and addressed them locally.Root cause observed
raise_on_emailkwarg onmail.thread._message_compute_author.fields.datetime.now()alias is gone; onlyfields.Datetime.now()remains.request.session["my_key"]/request.session.get("my_key")), not as attributes.res.groupsXML, the relation field isuser_ids(notusers).Working approach we implemented locally
mail.threadoverride signature todef _message_compute_author(self, author_id=None, email_from=None)and adjusted thesuper()call.fields.datetime.now()withfields.Datetime.now().request.session.impersonate_from_uidand similar to mapping-style reads/writes:request.session.get("impersonate_from_uid")andrequest.session["impersonate_from_uid"] = ....security/group.xmlto use<field name="user_ids" .../>.request.session.uid, recomputesession_tokenviaodoo.service.security.compute_session_token, and client reload). This still works in 19./web/action/load), we wrap thehelpstring with Owl’smarkup()in the client so that any HTML help renders like standard actions in 19. We also provide a styled empty-list helper (smiling face + paragraph) for the Switch Login selector.Key details
session_tokenrecomputation is unchanged and remains necessary in 19.ir.http.session_info()to exposeis_impersonate_userandimpersonate_from_uidremains the correct pattern.create_uid/write_uidattribution to the original user during impersonation continue to work in 19 once session keys use the mapping API.Questions
19.0branch forserver-authso we can open a PR forimpersonate_login? I currently don’t see a19.0branch to target.Testing
--stop-after-init, verified:create_uid/write_uidattribution preserved (original impersonating user)Happy to push the patch and a concise README note for 19.0 once the target branch is available.
Thanks!
— Milan Topuzov