Monday, September 7, 2026
7 changes · 19.0
Resolved issues and error corrections
Users can now update analytic information from the bank reconciliation widget without being stopped by lock date checks. This prevents an incorrect error when only the analytic distribution is changed, making reconciliation edits smoother while preserving normal lock date protections.
Original PR description
In the case of the bank rec widget, when modifying a line, we actually unlink it and create a new one. In that case, modifying the analytic would trigger the lock date error. But user should be allowed to modify the analytic all the time. In the edit of the bank rec widget, we add a context key that will be added if analytic distribution is the only key modified. task-6397993
This fixes an issue where changing only analytic information in the bank reconciliation widget could be blocked by lock date checks. Users can now adjust analytic details without being stopped by accounting period locks, while normal lock date protections remain in place.
Original PR description
In the case of the bank rec widget, when modifying a line, we actually unlink it and create a new one. In that case, modifying the analytic would trigger the lock date error. But user should be allowed to modify the analytic all the time. In the edit of the bank rec widget, we add a context key that will be added if analytic distribution is the only key modified. task-6397993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican POS self-invoicing test was updated to match the newer process where public users can no longer change existing customer details. This keeps automated checks aligned with the intended customer creation flow and helps prevent false test failures.
Original PR description
Before the related pr commit: - Public users could update customer data during the self-invoicing flow. - The test_qr_code_receipt_mx test relied on this behavior when updating customer data. After the ref commit: - Public users can no longer update customer data during self-invoicing. - Update test_qr_code_receipt_mx to create a new partner with the required customer data when the order is not linked to a customer. Related PR: odoo/odoo#283470 Task-6272660 Forward-Port-Of: odoo/enterprise#129948
This update fixes a typo in an Italian electronic invoicing withholding tax reason. It helps keep tax-related wording accurate and avoids confusion in Italian localization records.
Original PR description
Correction of a typo in italian withholding tax reason. opw-6514615 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resetting text color in the HTML editor no longer removes other formatting on the selected text, such as font size. This keeps document content looking as intended when users adjust or clear text colors.
Original PR description
Steps to reproduce: - Open the first default To-do note. - Select the word Welcome. - Open the text color picker. - Click the trash icon to reset the text color. Issue: - When resetting the text color, the selected text also loses its font-size style. Cause: - The `color_plugin` removes the wrapper element after resetting the color style. If the same element also contains other inline styles (such as font-size), those styles are lost when the element is removed. Solution: - After resetting the color style, only remove the element if it no longer has any other inline styles. Otherwise, keep the element so that the remaining styles are preserved. task-6279198 Forward-Port-Of: odoo/odoo#282529 Forward-Port-Of: odoo/odoo#275550
Invoice PDFs for Guatemala and Uruguay now show the correct identification label based on the customer's selected document type. This prevents confusing or incorrect tax ID labels on customer-facing invoices.
Original PR description
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is…
Currently invoice reports use the label related to the company's country for the partner's vat number, however in the case of latin america countries, a new field l10n_latam_identification_type_id is added to partners that allows the use of different identification types. This results in invoice reports showing the identification number next to an incorrect label. This commit fixes the issue for Guatemala and Uruguay by overriding the vat label in their respective invoice template to match the selected identification type. Steps to reproduce: - Install a latam localisation (Uruguay or Guatemala) - Change company to that country's Company - Create a partner located in said country, ensure the identification number is set to something else than the default one - Create an invoice for the partner, confirm it, and then Send it - In the pdf generated for the invoice you will see that under the partner's address the "vat number" has the wrong label opw-6087359 related to: https://github.com/odoo/odoo/pull/260159 Forward-Port-Of: odoo/enterprise#122512
Blog articles now make bold formatting visibly stand out even when the surrounding text uses a light font style. This helps editors and readers see emphasized text as intended, improving readability and content presentation.
Original PR description
Problem: When a parent element applies a `font-weight: 300` to its content, a child `<strong>` tag defaults to `font-weight: bolder`, which resolves to a computed font weight of `400`. For certain font families, weight `400` is visually identical to `300`, leaving no visual distinction for bold text. Cause: `<strong>` tags relied on relative weight boosting (`bolder`), which only increases the parent weight from `300` to `400` instead of applying explicit bold weight. Solution: Explicitly set `font-weight: bold` on `strong` for `.o_wblog_read_text` Steps to reproduce: - Go to /blog - Open any blog - Open editor. - Select some text from the content of the blog. - Apply Bold. - Observe that there is no visual difference. opw-6460699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282667