Tuesday, December 2, 2025
13 changes · 18.0
Enhancements to existing features
This update brings Odoo's Swissdec ELM Certification in line with version 5.3, incorporating key regulatory changes. Specifically, it adds support for new French-crossborder rules, adapts to the AVS21 regulation regarding retirement, and automates allowance calculations. This ensures continued compliance and accurate reporting for Swiss payroll.
Original PR description
This Pull request extends the Odoo Swissdec ELM Certification to the minor version 5.3. By doing so we add the following features : - Telework Percentage declaration for French-crossborder comuters - Adapting to AVS21 regulation, where retired employees can refuse their right to retirement - Adding automatic Child and education allowance calculation - Add the calculation of LPP in % - Allowing the specification of custom employer parts for LAAC and IJM Forward-Port-Of: odoo/enterprise#95518
This update ensures Odoo correctly handles German B2G invoices in the XRechnung format. It adds a mandatory 'Leitweg-ID' – a routing identifier – to the invoice XML, directing invoices to the appropriate government entity as required by German regulations. This improves compliance and accuracy for German business transactions.
Original PR description
*= l10n_account_edi_ubl_cii_tests For B2G transactions in Germany, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. Adding this Leitweg-ID for the UBL syntax. task-5194484 Description of the issue/feature this PR addresses: For electronic invoicing in Germany, for B2G transactions, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. We want to add this identifier for the XRechnung format. Current behavior before PR: The Leitweg-ID is not present in the UBL xml format. Desired behavior after PR is merged: The Leitweg-ID is added in the header of the invoice in the cbc:BuyerReference tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236333
Resolved issues and error corrections
This update resolves a crash in the 'Update Tax Tags' wizard when a company has a tax lock date configured in Odoo v18. The change reintroduces a mechanism to ensure the wizard correctly loads company data, preventing a type error that occurred during date comparisons. This ensures the wizard functions reliably for all users.
Original PR description
Opening the `Update Tax Tags` wizard in v18 crashes when the company has a tax lock date configured, raising: ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` The…
Opening the `Update Tax Tags` wizard in v18 crashes when the company has a tax lock date configured, raising: ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` The error happens because `_compute_display_lock_date_warning` is evaluated while date_from is still False, so the comparison `wizard.date_from < tax_lock_date` ends up comparing a boolean with a date. In v17 the wizard form view included an invisible company_id field, which ensured the company was properly loaded in the cache and allowed `_compute_date_from` to run with the correct company_id and tax_lock_date before the warning compute was triggered. This change reintroduces the invisible company_id field in the wizard form view to restore the v17 behavior. The wizard now loads the company correctly, computes `date_from` based on the tax lock date, and then computes `display_lock_date_warning` without triggering the TypeError. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users lacking the correct permissions couldn't upload documents to activities. The fix now checks user rights before attempting to upload, preventing errors and ensuring proper functionality for all users.
Original PR description
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for…
Step To Reproduce: - install Project - login with admin and open any Project settings, say Project 1. - create a upload document activity for 'marc demo' - ensure marc demo has 'User' access for project - login with marc demo - open same project (kanban card -> view) - upload a document for the created activity Observation: - Traceback ``` TypeError: Cannot destructure property 'id' of '(intermediate value)' as it is undefined at Activity.onFileUploaded ``` Cause: - upload request to `/mail/attachment/upload` , calls `mail_attachment_upload` which then tries to access thread for 'write' mode, 'project.project ' model . - as marc demo does not have write access to this model, no thread is returned - so `NotFound()` is raised https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mail/controllers/attachment.py#L48-L55 Fix: - we check if selected user has appropriate rights or not for upload activity opw-5160132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up the process of matching bank transactions with sales orders. By optimizing a key database query, the system now completes this task much faster – reducing the time from 3.88 seconds to just 0.27 seconds. This improvement enhances overall system performance and responsiveness.
Original PR description
Finding a match between the bank transactions and sale orders is currently done via an unoptimized query that is preventing postgres from using any index. This commit removes the unnecessary CTE by simply doing the query directly on the sale_order table. This way we can also use a trigram index on the regex used for matching and postgres will be able to utilize it for faster search. Benchmarks: | Num sale_order | Before | After | | -------------- | ------ | ------ | | 1391909 | 3.88 s | 0.27 s | Ticket [link](https://www.odoo.com/odoo/project.task/5139457) opw-5139457 Forward-Port-Of: odoo/enterprise#100470
This update fixes a bug where error messages weren't being properly handled during retry attempts, leading to build failures. The change ensures that traceback errors, previously bypassed, are now correctly processed, and also addresses an OSError related to websocket handling, improving overall system stability.
Original PR description
The auto-retry is supposed to catch error logs as well as tracebacks. In some cases a traceback is logged as a message, and not as a logger arg, bypassing the replace already in place. This pr simply replaces the traceback string in the message as well. Build error [234619](https://runbot.odoo.com/odoo/runbot.build.error/234619) Also fixes OSError while handling request paused Build error [229906](https://runbot.odoo.com/odoo/runbot.build.error/229906) Forward-Port-Of: odoo/odoo#238133
The product configurator now functions reliably, even when multiple product variations share the same underlying attribute. This fix resolves a previous error that caused the configurator to fail, ensuring a smoother experience for users building custom products. This improvement enhances the overall stability and usability of the product configuration feature.
Original PR description
Description of the issue/feature this PR addresses: When multiple `product.template.attribute.line` records reference the same `product.attribute`, the product configurator raises a `KeyError` at…
Description of the issue/feature this PR addresses:
When multiple `product.template.attribute.line` records reference the same `product.attribute`, the product configurator raises a `KeyError` at line 321.
Root cause: `ptals.attribute_id` returns a unique recordset (Odoo deduplicates), so `zip(ptals.ids, ptals.attribute_id.read(...))` produces fewer entries than expected when attributes are shared across lines.
```python
# Before: zip stops at shorter list, missing entries in attrs_map
attrs_map = dict(zip(ptals.ids, ptals.attribute_id.read(['id', 'name', 'display_type'])))
# After: preserve 1:1 mapping by iterating each ptal
attrs_map = {ptal.id: ptal.attribute_id.read(['id', 'name', 'display_type'])[0] for ptal in ptals}
```
Current behavior before PR:
`KeyError` raised when accessing `attrs_map[ptal.id]` for attribute lines whose ID was truncated by the `zip`.
Desired behavior after PR is merged:
Product configurator correctly maps all attribute lines regardless of whether they share the same underlying attribute.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes several issues within the Odoo spreadsheet component, improving its stability and performance. It addresses problems related to figure display, data calculations, and sheet updates, ensuring a smoother user experience. Multiple developers collaborated on this update to ensure comprehensive improvements.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7ed20c4cf [REL] 18.0.50 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7ed20c4cf [REL] 18.0.50 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ca9b40487 [FIX] figure: wrong focus change on figure unmount [Task: 5154025](https://www.odoo.com/odoo/2328/tasks/5154025) https://github.com/odoo/o-spreadsheet/commit/cd6c2d8de [FIX] pivot: Ensure computed measure range adaptation [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/fc4196b30 [FIX] commands: remove duplicate in invalidateEvaluationCommands [Task: 5358213](https://www.odoo.com/odoo/2328/tasks/5358213) https://github.com/odoo/o-spreadsheet/commit/790c2c5e5 [FIX] composer: keep edition mode inactive on cursor selection change [Task: 5354541](https://www.odoo.com/odoo/2328/tasks/5354541) https://github.com/odoo/o-spreadsheet/commit/91a6b8948 [FIX] BottomBarSheet: sheet name should update on foreign changes [Task: 5016252](https://www.odoo.com/odoo/2328/tasks/5016252) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where printing receipts with reward lines and multiple order lines would cause the printer to block. The fix reorders how discounts are applied to prevent errors related to small discount amounts, ensuring receipts print correctly and reliably. This improves the user experience for sales transactions involving rewards.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale
This update fixes issues where video settings were lost or not applied correctly when saving configurations or embedding videos. Specifically, it ensures that video options from URLs are properly captured and applied, and that previews of Dailymotion videos function reliably. This enhances the user experience when adding and managing videos within the platform.
Original PR description
Issues: 1. Resetting options when dialog is closed without modification: When the media dialog is closed without changing any options and "Add" is clicked, the videoSelector component is reset,…
Issues:
1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and toggle a few options (e.g., "Loop").
- Save the video configuration.
- Double-click the snippet again to open the video configurator.
- Save without making any changes.
- The options will be reset.
2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.
- Steps to reproduce:
- Add any Text snippet.
- Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
- Choose to embed the YouTube video from the Powerbox popup.
- The Video snippet is added without options enabled for the pasted URL.
3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.
- Steps to reproduce:
- Drop a Video snippet.
- Double-click the snippet and append query parameters to the URL.
- The option buttons should toggle according to the parameters, but they do not.
4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....
- Fixes implemented:
- Preserve selected options when saving the Video snippet without any changes.
- Retrieve all query parameters from the URL and include them in the RPC request.
- Synchronize option toggles with the URL input when the user manually edits it.
- Fixed the Dailymotion regular expression to support protocol-independent
URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).
task-4529118
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210596This update resolves a problem where PayPal payments were failing due to missing shipping address information. The fix adds a default value to shipping address fields, ensuring successful Stripe payment processing. This improves the reliability of our payment system.
Original PR description
Paypal was failing when the address fields were `False` **Solution:** Add a fallback to missing fields in the shipping address Fixes: https://github.com/odoo/odoo/issues/237360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue where taxes weren't correctly shown in company currency on Argentinian invoices. The previous code was unintentionally removing the tax section, even when the 'Taxes in company currency' option was enabled. This change ensures invoices accurately reflect tax amounts in the appropriate currency.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Switch to a Argentinian company (e.g. (AR) Responsable Inscripto) - In Accounting settings, enable "Taxes in company currency" option - Activate another currency (e.g. USD) - Create an invoice in USD - Confirm the invoice - Print the invoice **Issue:** The section showing the taxes in the company currency doesn't appear on the invoice despite the enabled option. Cause: An override of "report_invoice_document" from l10n_are is removing the section no matter what the configuration. **Solution:** Do not remove the section. It was done originally in 17.0 where "Taxes in company currency" option didn't exist. opw-5351010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Invoice to Public' setting in the Mexican Point of Sale (POS) app was failing to save correctly, resulting in an error. The fix ensures that this setting is properly updated in the system's database, allowing users to correctly generate public invoices when needed. This prevents a frustrating user experience and ensures compliance with Mexican regulations.
Original PR description
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice…
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035