Thursday, August 21, 2025
7 changes · 17.0
Resolved issues and error corrections
Saudi electronic invoicing no longer blocks invoices when a branch company uses a journal linked to the main company. The system now chooses the correct company details for QR code generation, helping branch setups process compliant invoices more smoothly.
Original PR description
This commit removes the previously enforced restriction in https://github.com/odoo/odoo/commit/d6175d0552c18006913e969eac7006666164609c that required the company specified on an invoice to match the company specified on the associated journal and makes sure that the company used to create the QR is the appropriate company whether in a branch or in a main company task-5005477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restricted website editors could edit certain website pages but then hit an access-rights pop-up when saving content tied to page templates. This fix prevents those restricted users from being offered edits they cannot save, reducing confusion and failed website updates.
Original PR description
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival"…
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival" - user is able to edits is footer contents,make a change - try to save. Observation: A pop-up for access right appears Cause: after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , we allow website to be editable for restricted user if, user can modify other models, which are editable from website,like event. And, if website is editable, we brand the ir.ui.views nodes, https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94 but restricted user do not have access to ir.ui.view model, causing access issue Note: if a node is branded, that means it is editable Fix: Brand ir.ui.view nodes only if user has full access to website editor opw-4659114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updates two Spanish 0% sales taxes so they are correctly treated as exempt with the proper legal exemption reasons. This helps Spanish tax reporting and electronic invoicing use the right classification, while removing older duplicate exempt tax entries that are no longer needed.
Original PR description
Currently 2 sales taxes are misconfigured.
They both should be marked as 'exento' ("Exento") instead of 'no_sujeto_loc' ("No Sujeto por reglas de Localization")
- "0% EU G"; with "Exempt Reason" E5 / "Art. 25"
- "0% EX G"; with "Exempt Reason" E2 / "Art. 21"
This commit updated those taxes
Due to this the following sales taxes become obsolete.
- "VAT Exempt (Art. 21)"
- "VAT Exempt (Art. 25)"
They are deleted in this commit.
opw-4850585This update refreshes Odoo's spreadsheet engine and fixes an issue where Excel files with formula-based conditional formatting could not be imported correctly. It helps users bring spreadsheet data into Odoo more reliably, especially when working with formatted XLSX files.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1592964d8 [REL] 17.0.71 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4b9a5667d [FIX] xlsx: cannot import CF with formulas [Task: 4945945](https://www.odoo.com/odoo/2328/tasks/4945945) https://github.com/odoo/o-spreadsheet/commit/c4ac43c1d [IMP] demo: Add error handler [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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: Ronak Mukeshbhai Bharadiya <rmbh@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 fix ensures expense payment entries are ordered so German DATEV general ledger exports pick up the correct tax-related line. It prevents missing BU tax codes in CSV reports for company-paid expenses, improving accounting report accuracy.
Original PR description
When creating a payment for an expense, the outstanding line was added as the last line. This creates an issue in the l10n_de DATEV DATA general ledger report. - Create an expense for a contact paid by the company and generate the report. - Approve the expense and post the journal entries. - In the general ledger, download the DATEV DATA CSV file. - For the line corresponding to the payment of the expense, there is no BU code (tax). In _l10n_de_datev_get_csv, the first line of the move is considered the outstanding line, but in the case of expense payments it was actually the last line. As a result, the outstanding line was included instead of the line with the tax. opw-4904057 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The French point of sale compliance report now avoids loading unnecessary order data when checking inalterability. This reduces memory consumption significantly for companies with large POS order volumes, helping reports run more reliably.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#222416
This fix ensures Mexican electronic invoices use the same issue date and time as the posted invoice. It also keeps record locking reliable during sending, reducing the risk of inconsistent or duplicate processing.
Original PR description
'fecha_datetime' could be set to a different value than the 'document_post_time' passed as parameter because of the "min". We also must revert the `env.cr.commit` during the sending because it removes the lock on records. Instead we set the invoice post time and commit before locking. task-none