Thursday, May 7, 2026
22 changes · 18.0
Resolved issues and error corrections
This update fixes a limitation in how Odoo updates its UNSPSC product codes. Previously, new codes could only be added during initial module installation. Now, an upgrade script automatically adds new codes to the database when updates are applied, ensuring our product data remains current with industry standards.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update corrects a bug in the Mod 349 report for Spanish tax filings. Previously, amounts less than 1 Euro were incorrectly excluded, preventing the report from displaying relevant journal entries. The fix ensures that all financial lines, including those with small values, are accurately included in the report.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#114776
This update fixes an issue where the Point of Sale system wouldn't correctly manage multiple open rescue sessions. Now, when multiple sessions exist, a list view is displayed to select the appropriate one. If only one session is open, the system uses the standard direct form view for easier management.
Original PR description
When multiple rescue sessions existed for a POS config, calling `open_opened_rescue_session_form` raised a ValueError ("Expected singleton") because `.id` was accessed on a multi-record set.
Now opens a filtered list view titled "Rescue Sessions" when multiple open rescue sessions are found, and a direct form view when there is only one.
opw-6184661
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262829This update fixes a minor calculation error in the Swiss payroll module (l10n_ch_hr_payroll) related to the reversal of Quebec Sales Tax (QST). The change ensures accurate tax reporting, aligning with Swiss tax regulations and improving the reliability of payroll data. This update was triggered by a previous fix and is a routine maintenance update.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update fixes an issue where website event descriptions were often filled with irrelevant information, making them unsuitable for calendar views. The change now utilizes the event's subtitle as the description, ensuring a concise and accurate representation of the event in the calendar. This improves the clarity and usability of event scheduling.
Original PR description
When website_event is used the "description" becomes the main page of the event and can contain lots of completely irrelevant information in the first 1900 characters that are normally used for the calendar event description. In that case we should use the subtitle as the description instead as it's a lot more likely to consisely describe the event. task-5221382
This update fixes an issue where freight charges were incorrectly applied to all pickings, particularly with backorders. The change ensures freight costs are only included in the initial picking, aligning with how delivery costs should be invoiced to the customer and accounting for potential changes in delivery costs.
Original PR description
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are…
Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result: 1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings. 2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself. Solution ----- For the first problem, there are a couple things to keep in mind: - the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer - products can be added and removed from the picking after the SO has been confirmed - actual delivery cost can change between invoice date and actual delivery date - picking can be split into multiple packages at the user's discretion Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders. ----- Ticket: opw-6013387
This update fixes a bug that could occur when consuming stock valuation layers linked to returned moves, particularly when products used different unit of measure categories. The fix ensures the correct unit of measure is used during quantity conversion, preventing a 'singleton' error and improving the stability of stock valuation processes.
Original PR description
#### Issue: Consuming stock valuation layers linked to returned moves could raise an error when the SVL recordset contained products from different UoM categories. #### Cause: `_consume_specific_qty()` and `_consume_all()` used `self.uom_id` inside per-record loops. When self contained SVLs from different UoM categories, self.uom_id was multi-record, causing quantity conversion to fail with: `ValueError: Expected singleton: uom.category(2, 6)` #### Fix: Use the UoM of the current SVL record during returned quantity conversion: - `candidate.uom_id` in `_consume_specific_qty()` - `svl.uom_id` in `_consume_all()` opw-6119427 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the navbar menu items and app icon would disappear when users zoomed out or increased the screen width on mobile devices. The fix ensures the navbar dynamically adjusts to display the full menu and icon when sufficient screen space is available, improving the user experience.
Original PR description
**Issue:** In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout. **Fix:** The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes. **Before:** After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden. **After:** When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected. opw-6107660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a misleading validation error that appeared when using the translation button on Sale Order Templates, particularly within O2M views. The fix ensures the system correctly handles nested records, preventing unnecessary error messages and improving the user experience. This change ensures users can accurately translate descriptions without confusion.
Original PR description
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing…
Steps to reproduce: * Enable multiple languages * Go to Sale Order Templates and create a new template * Add a product line, then click the translate button on the description field * A confusing validation error appears for missing `sale_order_template_id` Issue: * Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id` Cause: * `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead. Affected Version: 17.0 Before: <img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" /> After: <img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262755
This update ensures that the terms and conditions displayed to customers are translated into their preferred language, rather than the administrator's. Previously, the system incorrectly used the administrator's language, leading to inconsistent and potentially confusing customer experiences. This fix corrects a technical issue and improves the accuracy of translated content.
Original PR description
## Problem
When `terms_type == 'html'`, a `context` dict with the partner's language was created but immediately deleted without ever being applied. As a result, `_()` ran in the admin's language instead of the partner's language:
```python
context = {'lang': order.partner_id.lang or self.env.user.lang}
order.note = _('Terms & Conditions: %s', baseurl)
del context # context was never used
```
This was introduced in 466ee8f5fe48 and left unaddressed when 07b9d0e2307b fixed the plain-text branch.
## Fix
Replace the unused context dict with `with_context(lang=lang)` so the translation is evaluated in the partner's language (or the user's language as fallback), consistent with the `elif` branch below.
## Steps to reproduce
1. Configure HTML terms and conditions with translations in two languages
2. Create a sale order for a partner with a language different from the admin's
3. The `note` field stores the translation in the admin's language instead of the partner'sThis update ensures that invoices sent to users in the 'smp_registration' state (pending) are now correctly processed by the system's automated invoice retrieval process. Previously, these invoices were missed, leading to potential delays. This change improves the efficiency of invoice handling and ensures all incoming invoices are captured.
Original PR description
Previously, invoices sent to users in "smp_registration" state (pending) were not fetched by the cron. This commit allows retrieval of incoming invoices while the user is still in "smp_registration" state (pending). task-6110730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where pressing backspace at the edge of a button caused a crash. It also corrects the backspace behavior, ensuring that the cursor accurately deletes characters when pressing backspace at the button's left edge. This enhances the overall stability and usability of the HTML editor.
Original PR description
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the…
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left. **How to reproduce** In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown. **Why the problem happens** 1. Traceback when backspace is pressed `LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash. 2. No deletion of the character to the left of the cursor `DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp. **Fix** 1. Prevent the crash in `LinkPlugin` `LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns. 2. Fix backspace behavior in `DeletePlugin` `deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left. task-6102282
This update corrects a bug where the 'Purchase Orders' button disappeared from analytic accounts when the account plan was changed. The fix adjusts how the system searches for purchase order counts, ensuring it correctly identifies orders linked to the updated analytic account plan. This ensures users can always access relevant purchase order information.
Original PR description
# How to reproduce - Enable the analytic accounting in the settings - Create a PO - Add a PO line - Set the Analytic Distribution of that PO line to an Analytic Account of your choice - Confirm the…
# How to reproduce
- Enable the analytic accounting in the settings
- Create a PO
- Add a PO line
- Set the Analytic Distribution of that PO line to an Analytic Account of your choice
- Confirm the PO
- Create a Vendor Bill from that PO and confirm the VB
- Go to the Analytic Account chosen before
- Change the Plan of that Analytic Account
# The problem
When the Plan is not set to the "Project Plan", the Purchase Orders smart button disappears
# Why
The Purchases Orders smart button is invisible if the variable purchase_order_count is equal to 0. That field is computed by a function that does a search with the following domain :
```py
[('order_line.invoice_lines.analytic_line_ids.account_id', '=', account.id)]
```
When we change the Plan of the Analytic Account, analytic_line_ids.account_id is set to NULL, so the search return nothing.
Why is that field set to NULL ?
Well, to reference its plan, an Analytic Line does not use a python-defined field. In fact, each time a new Analytic Plan is added to the database, a new column is added to the Analytic Line model. That column's name is x_plan{plan.id}_id or, for the specific case of the "Project Plan", it is account_id
When the Plan of an Analytic Account is changed, it takes every Analytic Line associated with that Plan and switch which column containing the id of the Analytic Account.
Take for exemple the following Analytic Line :
```
(account_id = NULL, x_plan2_id = NULL, x_plan3_id = 1)
```
When the associated Analytic Account's Plan is changed to the "Project Plan", it becomes :
```
(account_id = 1, x_plan2_id = NULL, x_plan3_id = NULL)
```
So, we need to adapt to search so that it uses the right plan's name.
opw-5897037
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue preventing the sales team from opening milestones within projects created from sales orders. The fix utilizes a temporary bypass of access restrictions to correctly calculate quantities, ensuring users can now manage milestones effectively. This improves the sales process by allowing for better project tracking.
Original PR description
Steps to reproduce: - Install the sale_project module - Create a sale order based on milestones - Create the project from the order - Open the project, click the three dots, and open a milestone Issue: Users are unable to open milestones and get an access error. Cause: Users in `sales_team.group_sale_salesman` lack read access to the related `sale.order.line`, causing an AccessError when `sale_line_id` is accessed during the computation of `product_uom_qty`. Fix: Compute `product_uom_qty` using `sudo()` to bypass record rule restrictions. task-5477304 Forward-Port-Of: odoo/odoo#245392
This update fixes an issue where public holidays without a defined working schedule were not appearing in payroll reports. The change expands the system's search criteria to include all public holidays, regardless of whether they have a working schedule associated with them. This ensures accurate reporting for all holiday scenarios.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070 Forward-Port-Of: odoo/enterprise#114900
The budget report was incorrectly displaying amounts from analytic lines that weren't linked to any budgets. This update fixes a bug in the SQL query that prevented the report from properly filtering out these unbudgeted lines. Users will now see only budgeted amounts in the report.
Original PR description
**Issue:** Budget report shows analytic lines that are not linked to any budget report lines. **Steps to reproduce:** In a new company with no analytic budgets, - Create one analytic item. - Open the budget report and remove the default "open budget" filter. You will see the amount from the analytic line (in pivot view) or the whole line (in list view) even though the analytic line doesn't belong to any budget. **Cause:** The SQL else clause is not only covering the `ba.budget_type = 'both'` but also the case where there is no matching budget `ba.budget_type = None`. **Fix:** Explicitly handle both cases `ba.budget_type = 'both'` and the else (`ba = None`). opw-6051696
This update fixes a flaw in the Microsoft Calendar sync tests. Previously, the tests were evaluating the sync immediately after creation, rather than after a reasonable delay. This change ensures the tests accurately verify the calendar synchronization process after events have been created.
Original PR description
A sync test added with 48b212189331c3c94dff5764a672e9b12678d92b is not actually testing the fix as the sync is done with the same mocked time as the create/write whereas the whole point is to check the sync after some time passed from create/write opw-5212908
This update addresses a technical issue within the Odoo spreadsheet component, specifically related to chart visibility. The changes ensure that chart values remain fully visible by removing clipping, improving the user experience. This update also includes standard code improvements for consistency and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/24a7e5513f [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/24a7e5513f [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/f36e6ce39f [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827) https://github.com/odoo/o-spreadsheet/commit/17db4384c7 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) 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 fixes an issue where HR leave requests with 'both' approval types didn't send notifications to the designated responsible parties. The change ensures that notifications are correctly sent to the 'Notified Time Off Officer' when this approval type is selected, improving the accuracy of leave request workflows.
Original PR description
…cer') no fallback for responsible_ids
Issue:
When ('both','By Employee's Approver and Time Off Officer') is selected on a new HR Leave Type it does not fall back to the responsible_ids or “Notify HR”.
Steps:
1) Setup a neutralized outgoing mail server
2) install hr_holidays
3) make a new hr.leave.Type (Approval) with ('both','By Employee's Approver and Time Off Officer') and select a 'Notified Time Off Officer'(responsible_ids) 4) select an emplyee with a reelated user and remove the coach, manager, and responsible 'Time Off'. 5) save
6) Sign in as the employee, make a time off request under the new Type 7) No email
Fix:
Add a conditional with the lowest priority to fall back to responsible_ids
opw-6101637
Forward-Port-Of: odoo/odoo#261853The budget report now accurately displays data without duplicate analytic lines. This issue stemmed from a recent performance optimization that inadvertently created duplicate entries. The fix ensures unique reporting by using a more precise query structure.
Original PR description
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item…
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item (linked to Analytic Account A). - Open the budget report and remove the default "open budget" filter. Duplicate amounts appear in the pivot view and duplicate lines appear in the list view. #### Cause: In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report. #### Fix: Use three separate queries, each with specific filter conditions to guarantee unique results: Q1 - Analytic lines with no matching budget line. Q2 - Analytic lines matched to a budget line with no company (null-company). Q3 - Analytic lines matched to a company-specific budget line. OPW-6051696
This update fixes an issue where the shipping weight in package creation was incorrectly calculated, using the total weight of all delivery lines instead of just the selected ones. This ensures accurate weight calculations for package preparation, leading to more precise shipping costs and inventory management. The change impacts the stock delivery module.
Original PR description
Issue ----- When putting a subset of lines in a pack, the wizard computes the weight as if all of the picking's lines were selected. Steps to reproduce ----- - Enable packages - Create a packaging type for carrier "No carrier integration" (std delivery) - Create 2 products with different weights - Create a delivery - Add a demand for both products - Additional Info > Carrier: Standard delivery - Mark as Todo - Open the moves view - Select one of the 2 lines - Click Put in pack - Select the package type > The "Shipping Weight" is the picking's weight instead of the selected line's ----- Ticket: opw-6125285
This update fixes an issue where some UBL invoices were being incorrectly processed. The change ensures that invoices with a valid CustomizationID are prioritized, improving the system's ability to correctly interpret UBL invoices. A fallback mechanism remains in place for unknown formats to maintain compatibility.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263285