Saturday, September 19, 2026
2 changes · saas-19.1
Resolved issues and error corrections
Refund totals on certain Argentine invoice reports now show with the correct negative sign, matching the invoice lines. This prevents confusing or misleading totals for document types where VAT is not separately detailed.
Original PR description
Follow-up of #212153. `_l10n_ar_get_invoice_totals_for_report` applies `_apply_refund_adjustments` twice on the same dict: once at the beginning and again right before excluding the tax groups that must not be detailed on the report. For document types where VAT is not detailed (letters B, C, X, R, e.g. codes 188 and 189 "Liquidación de compra directa sector pecuario") the second call undoes the first one, so the totals are printed in positive while the lines are printed in negative. This PR removes the second call so the sign is applied only once, and adds a test covering the VAT-included path with document type 188. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now lets customizations change which flag image is shown for a language without redefining the whole field. This matters for businesses that need regional or market-specific language presentation while keeping upgrades simpler.
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