Saturday, September 19, 2026
2 changes · saas-19.2
Resolved issues and error corrections
In Discuss, users can now hold Shift while selecting emojis from the quick reaction menu to add multiple reactions without reopening the picker each time. This restores the intended behavior and makes reacting to messages faster and less repetitive.
Original PR description
When adding a reaction to a message in Discuss, selecting an emoji adds the reaction and closes the emoji picker. This can be inconvenient when adding multiple reactions in a row, as the picker has to be reopened every time. To address this problem, the emoji picker remains open when the user holds Shift while selecting an emoji. However, this behavior was overlooked when implementing the Quick Reaction Menu, which therefore closes the emoji picker upon emoji selection, regardless of whether Shift is pressed. This commit fixes the Quick Reaction Menu so that holding Shift while selecting an emoji once again prevents the emoji picker from closing. [Task-6575382](https://www.odoo.com/odoo/project/1519/tasks/6575382) Forward-Port-Of: odoo/odoo#289081 Forward-Port-Of: odoo/odoo#288336
This fixes how Odoo determines the flag image shown for a language so custom modules can override that choice. Businesses can now better match language options with regional or market-specific flags without duplicating field definitions or using workarounds.
Original PR description
Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a…
Which flag stands for a language is a presentation choice, not a property of its code. `_compute_field_flag_image_url` derives the URL from the country part of the locale, and a site that wants a different flag for a language it offers, a regional one or the flag of the country it actually serves rather than the one the code names, has to compute that URL its own way.
That is not possible today. The field passes the compute as the function object:
flag_image_url = fields.Char(compute=_compute_field_flag_image_url)
`determine()` takes the `callable` branch and calls that object with the recordset. A plain function is not bound, so the implementation of `base` runs whatever class the record has: a module that inherits res.lang and defines `_compute_field_flag_image_url` changes nothing, and nothing says so. No error, no warning, and the field keeps answering the same URL. Getting around it means redeclaring the field only to replace its compute, which is more than the situation calls for.
Passing the method name puts the computation back on the MRO and costs nothing else: `Field.get_depends` resolves a string with `resolve_mro` and collects `_depends` from every implementation it finds, so the `@api.depends('code', 'flag_image')` declared here keeps applying, to this implementation and to an override alike.
This is the same kind of fix as #185419, which made the `domain` of a field reachable by an override for the same reason. Two field declarations in the codebase still pass a function object this way; the other is `website.menu.is_mega_menu`, which passes `inverse` the same way and is left alone here.
Forward-Port-Of: odoo/odoo#288686