Friday, September 11, 2026
6 changes · 19.0
Enhancements to existing features
When Mexican electronic invoice documents are marked as cancelled, the system now records cases where the related journal entry cannot be cancelled automatically. This helps support teams investigate cancellation issues faster without changing the business flow.
Original PR description
In the current state, when an edi document is set to cancelled, the journal entry will attempt to cancel. However, if the cancellation throws a `UserError`, the flow simply continues. This PR adds a logger call to record the failure and help investigate the potential causes. Forward-Port-Of: odoo/enterprise#123511
Logs produced during tests that simulate time now show the actual system time again, making runbot and long-running test logs easier to interpret. The simulated time remains available separately when needed, preserving diagnostic information while improving day-to-day log analysis.
Original PR description
When using faketime the logs are not showing the real time but the faketime one which can be confusing when listed in the runbot interface. Before the usage of the JSONFormatter, the logs were using the PostgreSQL time, which is the real time. This restores the previous behaviour. Having the faked time oustide JsonFromater is also painful: long running faketimed tests end up with most of their logs stamped to nearly the same real date, preventing any analysis of execution time based on the logs. One drawback of this change is the inability to identify at first sight whether a log was faketimed or not, but at this point it is just a tradeoff, and the faked_created field on the record still allows getting this info if needed. Forward-Port-Of: odoo/odoo#287455 Forward-Port-Of: odoo/odoo#287159
Resolved issues and error corrections
The shop page wishlist heart button now displays consistently in Safari. This prevents product cards from looking misaligned, improving the shopping experience for Safari users.
Original PR description
The wishlist button on the shop page is misaligned in Safari Steps to reproduce: (in Safari) 1. Install eCommerce 2. Go to the shop 3. The wishlist button (heart icon in the top right corner of each product) is misaligned Issue: The wishlist button (`.o_add_wishlist`) is positioned with `position: absolute` with only top and right offsets set (through the `o-position-absolute` mixin), leaving its width and height on `auto`. https://github.com/odoo/odoo/blob/c4de5361fb207916175332dcf6815c0814ecf09c/addons/website_sale_wishlist/static/src/scss/website_sale_wishlist.options.scss#L62-L65 In other browsers, the button resolves to a 38 x 38px square box but in Safari, it is not a square which misaligns it in the product grid. Solution: Force width and height on `.o_add_wishlist`, so the button resolves to the same box size in every browser. opw-6456552
Fixed an issue where Turkish Nilvera e-invoices in foreign currencies could show the currency subunit in the customer's language, creating mixed-language amount text. The amount-in-words note is now consistently formatted in Turkish, helping invoices meet local e-invoicing expectations.
Original PR description
### Issue before this commit: When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the…
### Issue before this commit: When generating a Nilvera e-invoice in a foreign currency (e.g., EUR), the amount written in words inside the <cbc:Note> tag contained a mix of languages. While the numbers were correctly translated to Turkish, the currency subunit label was fetched using the customer's language. This resulted in a partially translated string (like "... SIFIR CENTS") instead of the expected fully Turkish text (like "... SIFIR SENT"). ### Steps to reproduce the issue: 1. Download Accounting and l10n_tr_nilvera_einvoice 2. Create an API KEY: https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0#heading=h.e6i8a29lff5t 3. Go to a turkish client on the Accounting tab and click on 'Verify' for the Nilvera status 4. Go to currencies and activate EUR (be sure there is also the translation for currency subunit) 5. Go to invoices, create one for the Turkish customer you already verified setting the currency as EUR and send it with Nilvera 6. See that current output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR CENTS</cbc:Note> (Turkish numbers with English subunit) but the expected output is <cbc:Note>YALNIZ : BEŞYÜZDÖRT EUR SIFIR SENT</cbc:Note> (Fully Turkish text) ### Cause of the issue: The issue occurs because the currency_subunit_label field is not translated but fetched using the language of the customer in the invoice. ### Reason to introduce the fix: To ensure that the amount in words inside the <cbc:Note> tag is completely formatted in Turkish, complying with Nilvera and local e-invoicing requirements, regardless of the customer language. opw-6523794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The quotation document form now clearly shows that an attachment must be selected before saving. This reduces confusion for users by highlighting the correct field needed to complete the form.
Original PR description
When trying to save an empty quotation document from the form view, the save is blocked because the `name` field is required. However, `name` is readonly when no attachment has been selected. As a result, the form doesn't display the required-field decoration on that field, which is confusing. The attachment field should be marked as required in the view instead. This makes it clear that an attachment must be selected first, after which the `name` field becomes available and can be filled in. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287400
The project overview now shows the upcoming milestone based on the milestone deadline rather than creation order. This keeps the project list consistent with the milestone list and helps users see the truly next deadline at a glance.
Original PR description
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent…
Issue: The project list could display the first created unreached milestone as the next milestone, even when another milestone had an earlier deadline. This made the project overview inconsistent with the milestone list. Steps to reproduce: - Create a project with milestones enabled. - Create MS1, then MS2. - Give MS1 a later deadline than MS2. - Open the project list and display the Next Milestone column. Cause: `_compute_next_milestone_id()` aggregated unreached milestones as an `id:recordset` and selected its first element. The ORM orders that aggregate by database ID, so creation order was used instead of the milestone model's deadline order. https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/addons/project/models/project_project.py#L209-L218 https://github.com/odoo/odoo/blob/765174be270813442df6c497456fe2864517da0b/odoo/models.py#L364-L377 Solution: Retrieve unreached milestones through their normal ordered search before grouping them per project. This preserves batched computation while ensuring that the selected record follows the established milestone order. opw-6496938 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286815 Forward-Port-Of: odoo/odoo#285933