Monday, April 14, 2025
7 changes · 17.0
Resolved issues and error corrections
This update brings Odoo's spreadsheet component up to the latest version and includes performance improvements in how spreadsheet content is processed. Users should benefit from smoother spreadsheet handling, especially when working with formulas or text-heavy content, with no expected workflow changes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c484787e0 [REL] 17.0.56 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c484787e0 [REL] 17.0.56 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c9cf612b8 [PERF] tokenize: faster space tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215) https://github.com/odoo/o-spreadsheet/commit/3d554b1ba [REF] tokenize: extract new line tokenize [Task: 4684215](https://www.odoo.com/odoo/2328/tasks/4684215) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This change reverses a previous update that slowed down numbering when processing large invoice batches. It restores stable performance so high-volume invoicing can complete more reliably and without unnecessary delays.
Original PR description
This reverts commit be20a51cf1787487bdf0bcb65fd20f0bb8b33dd4. The reverted change caused a performance regression when assigning sequences to large batches of invoices. Specifically, the sequence number and prefix were not written to the database during the transaction, causing `_get_last_sequence` to consistently return the first sequence in the batch. This resulted in an `O(n^2)` time complexity when searching for the next valid, non-duplicate sequence. opw-4711955 (non-exhaustive) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Nilvera e-invoices now include the required person details when billing individual customers rather than companies. This prevents invoice submission errors for non-company partners and improves compatibility with Turkey's Nilvera e-invoicing flow.
Original PR description
Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it.
Website forms using Cloudflare Turnstile now keep the loading indicator available when verification expires and show it again when users need to re-check. This prevents errors after the 5-minute token expiry and helps visitors complete forms reliably.
Original PR description
__Current behavior before commit:__ The Cloudflare Turnstile token expires every 300 seconds (see [Cloudflare doc][1]) which makes the widget reload. There was currently no callback handling this event. If the check had already succeeded, the spinner of the button would have been removed. Thus the second time `turnstileSuccess` would be called, `spinner` would be `null` and it would throw an error when reading `spinner.parentElement`. __Description of the fix:__ Hid the spinner in `turnstileSuccess` instead of removing it. Added an `expired-callback` to show the spinner back on the button. __Steps to reproduce the issue on runbot:__ 1. Enable and configure Cloudflare Turnstile 2. Go to the `/contactus` page 3. Check the box, wait 5 minutes and check the box again [1]: https://developers.cloudflare.com/turnstile/get-started/client-side-rendering/#:~:text=the%20next%20300%20seconds opw-4629962 opw-4681945 opw-4620019 opw-4615863 opw-4640032
This fix adjusts calculations in Spain's annual VAT report (Modelo 390) to avoid refund amounts being counted twice in key totals. It improves the accuracy of reported tax totals, especially in section 2, while partially correcting a known issue in section 1 until a broader future cleanup is made.
Original PR description
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details:…
In https://github.com/odoo/odoo/pull/205403 I did some wrong changes to the totals of Modelo 390 section 1. This PR reverts these changes and fixes the section 2, which was the initial plan. Details: l10n_es tax has two main tax reports, modelo 303 (quarterly taxes) and modelo 390 (annual taxes). For both of these reports, for invoices, the taxes use positive tax tags corresponding the to tax line in the tax report. For refunds, the two reports work differently. Modelo 303 links all the refund amounts to some special report line (modification/correction of base/taxes), whereas the modelo 390 uses the negative tax tags corresponding to the tax line in the report. The issue lies in the multiple cross report references from modelo 303 to modelo 390. In section 1, some base and tax amounts are referrenced from modelo 303, as well as the modification amounts (the total of refunds mentionned above). When we compute the totals for that section, some refunds can be counted twice (once from the report using the negative tax tags, and a second time if we count the modification cross referenced from modelo 303). Since we have more taxes using the negative tags than cross-referenced in that section, it is better to omit the modification from the totals (i.e. we do not subtract [30] for the totals, as the negative amounts are already accounted for for the majority of the taxes). The totals will still be incorrect for that section, but less wrong. A future PR for master will fix the report by splitting all the tags used for the two reports. In section 2, we are in a similar case, so we remove the subtraction of [62] from the totals. In this case, the totals are correct after this modification.
Invoices in Mexico can now show the Update SAT button even after a cancellation request is started. This helps users refresh the official SAT status and complete the cancellation workflow without getting stuck.
Original PR description
At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least…
At the moment, if a cancellation has been requested, the 'Update SAT' button isn't always visible on the invoice. Analysis: The condition for the 'Update SAT' button being visible is that at least one of the EDI documents falls under one of the domains in `_get_update_sat_status_domains`. In particular, the 'Update SAT' status is visible if there is an EDI document with the 'invoice_sent' status and whose SAT status is not 'cancelled' or 'skip'. If the user requests the cancellation of the CFDI before the SAT status is fetched for the first EDI document (which represents the sending of the invoice), its SAT status will be set to 'skip'. As a result, the 'Update SAT' button will no longer be visible, meaning that the user can not update the invoice's state from fetching the SAT status.  Fix: The Update SAT button should also be visible if there is a document in 'invoice_cancel_requested' whose SAT state is valid. opw-4375788
This update improves Swiss payroll ELM transmission by allowing manual source tax adjustments, making transmission errors clearer, and restoring employee work information and skills details. It also adds missing translations, helping payroll teams resolve issues faster and manage employee data more completely.
Original PR description
In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab