Tuesday, March 10, 2026
18 changes · 18.0
Resolved issues and error corrections
This update resolves an issue where the system incorrectly interpreted date columns in import files. Specifically, it fixed a problem where date formats like '2500/1222' were mistakenly identified as '%Y.%m.%d'. This ensures that import files are processed accurately, preventing import errors and improving data integrity.
Original PR description
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)…
## Description of the issue/feature this PR addresses: If you try to import an excel sheet for example with these column on sale order, but the issue is at every model: (this is an example)  First column: Client ref Second column: committment date Third column: Customer ## Current behavior before PR: When you upload the file to import, the extract_header_types calls _try_match_date_time that try to guess the date column. The first column makes the _try_match_date_time to guess that the format is %Y.%m.%d format . This is an error because that column does not contain a date . The reason is that check_patterns when convert the pattern to reg ex using `def to_re(pattern):` on base_import/base_import.py, does not escape the "." so it works as "every char" wildcard character on regex . ## Desired behavior after PR is merged: No error should appear and the correct date format from the right date column should be guessed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196477
This update resolves a bug on the Jobs page where selecting all offices would remove the previously applied country filter. The issue stemmed from an incorrect variable used in the filter link. The fix updates the variable to ensure the country filter remains active when selecting all offices.
Original PR description
Steps to reproduce: =================== 1. Navigate to the Jobs page. 2. Filter a specific country 3. Select all offices -> The country filter will be removed Cause: ====== the "All Offices" link inside job_filter_by_offices, the href uses 'all_countries=1' if is_remote else current_country_path but current_country_path is not defined anywhere Solution: ========= Switch to current_country_param Note: ===== The fix will be adapted in later versions opw-5947819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Odoo invoices for Danish customers were incorrectly formatted according to Peppol standards. The change skips adding redundant PartyIdentification information, preventing errors and ensuring compliance with regulations. This improves the accuracy of invoice submissions and avoids potential processing problems.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602
This update corrects a previous issue where users with the invoicing & banks role couldn't access specific transaction views. The change ensures these users have the necessary permissions to view duplicate and missing transactions, improving their ability to manage financial data. This resolves a restriction in the previous 19.0 release.
Original PR description
In 19.0 we made a fix to allow users with the invoicing & banks role, to have access to duplicate transaction and missing transaction. https://github.com/odoo/enterprise/commit/748660f7ad9ca30d59f00e69d42a24864f1764d3 https://github.com/odoo/enterprise/commit/6edc057a9c0459af2b6d625415b700daf6280520 This commit will allow user with that role to access those menus task-5998895
This update resolves an issue where users could incorrectly set both a start and end date simultaneously within the web_studio environment. The fix prevents this invalid configuration, ensuring date range fields are properly validated and displayed, improving data accuracy and usability. This change addresses a technical bug impacting the user experience.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670
This update resolves an issue where changing the 'Kitchen Note' on a POS order after a quantity update would cause an error. The fix ensures that the note is correctly updated in subsequent order changes, improving the reliability of the POS system for restaurant operations. This prevents order discrepancies and ensures accurate customer notes are recorded.
Original PR description
**Steps to Reproduce:** - Install `pos_restaurant_preparation_display`. - Open Register for POS "**Restaurant**" Shop. - Choose table > select food-item > send the order. - Update food-item quantity > send the updated order. - Update food-item '**Kitchen Note**' > send the note. **Error:** `TypeError - 'NoneType' object is not subscriptable` **Cause:** When the food quantity is updated, a new preparation entry is created for the increased quantity. During the first iteration, the display and order quantities are already merged correctly. However, in a subsequent iteration, the original key no longer exists in `quantity_data`. As a result, accessing a None value leads to a traceback. **Fix:** This commit skips the merge step when the original quantity entry has already been merged. sentry-7197024946
This update resolves an issue where product availability emails were sending large, full-size images, leading to slow email loading times. The fix ensures images are appropriately sized for email delivery, improving email performance and user experience. This change was triggered by a bug in how product availability notifications were generated.
Original PR description
Steps to reproduce in local: 1. Install `website_sale_stock` 2. Make a product variant with an image 3. To make it easy set field `Back in stock Notifications`'s value on this product with the help…
Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`
Issue:
- The image is a full-size image
<table>
<tr>
<th style="text-align: center;">Before</th>
<th style="text-align: center;">After</th>
</tr>
<tr>
<td style="text-align: center;">
<img width="1395" height="728" alt="Before"
src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
</td>
<td style="text-align: center;">
<img width="1383" height="662" alt="After"
src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
</td>
</tr>
</table>
opw-5915587This update fixes an issue where customers could set the subscription start date to 'False', leading to incorrect invoicing. The change prevents this removal, ensuring subscriptions are properly billed and accurately reflect the subscription's terms. This maintains accurate subscription tracking and billing.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303
This update resolves a technical issue where saving thumbnails for spreadsheets could sometimes fail due to a brief disconnect during the process. The fix ensures that thumbnails are reliably saved, improving spreadsheet functionality and preventing potential data loss or errors. This was a minor stability improvement.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update corrects a problem with Razorpay payments caused by customer names containing commas or exceeding 50 characters. The fix ensures Razorpay correctly processes payments by trimming commas and limiting customer names to 50 characters, preventing errors.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay. Forward-Port-Of: odoo/odoo#252444
This update streamlines the process of opening cashboxes for IoT devices. Previously, a redundant network check was performed, which has now been removed. This change improves efficiency and reliability by leveraging the existing websocket connection for communication.
Original PR description
Stable IoT Boxes can be reached using websocket, so it doesn't make sense to check the connectivity on local network before sending the "open cashbox" action. We then removed this check.
This update resolves an issue where changes to view settings (like Interval/Scale/Mode) in Odoo Studio weren't being saved properly. The fix ensures that these settings are persistently stored using local storage, providing a more reliable user experience for editing and customizing views.
Original PR description
Example of steps: - Open any Cohort/Gantt/Calendar view - Open studio - Try to change the default Interval/Scale/Mode - Save - Nothing has changed Theses three view uses `localStorage` to persist theses settings, studio needs to update them directly via `localStorage.setItem` to do it properly. WIP opw-5951702
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits within the same field could lead to incorrect 'dirty' status indicators. Now, the system reliably tracks changes within the HTML editor, ensuring users receive accurate feedback on modifications.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348
This update resolves a technical issue related to XML files used for processing payments in Sweden (pain.001.001.09). The change ensures the correct XML format is used, aligning with industry standards and improving the reliability of payment processing. This update primarily impacts the handling of financial data in Sweden.
Original PR description
In Sweden, pain.001.001.09 XML files should use `<BICFI>` node, not `<BIC>`. This commit fix an XML test file to use BICFI. runbot-241221
This update ensures the Odoo spreadsheet component is running the latest version (18.0.59). This fixes a pivot issue where granularity wasn't being correctly applied and improves the overall stability and performance of the spreadsheet functionality. This change is a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3c93282146 [REL] 18.0.59 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/01c31da8a9 [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) 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>
A recent issue in our automated testing process (Distro builds) was causing failures related to barcode scanning and package quality checks. This fix increases the delay in the testing process to ensure backend operations complete before the UI updates, preventing intermittent errors and improving overall stability.
Original PR description
Distro builds was failing with:
```js
FAILED: [8/14] Tour test_quality_check_packages_lots_tour →
Step .o_line_button.o_toggle_sublines
{
'trigger': '.o_line_button.o_toggle_sublines',
'run': 'click'
},
```
- This issue occurs due to a timing race condition in the barcode client action.
After scanning lots and clicking Put in Pack, backend calls are
still processing (updating move lines and packages) while the frontend re-renders the UI,
the tour continued before these operations were fully completed,
so the `.o_toggle_sublines` button was not yet available in the DOM.
This caused intermittent failures, mainly in slower CI environments like Distro builds/runbot.
- To fix this, the tour step_delay has been increased from 100 to 300,
giving enough time for backend processing and UI rendering
to complete before executing the next step.
---
runbot error:238452This update corrects a bug in the holiday calculation for 'sandwich leave' when public holidays are involved. Previously, the system incorrectly calculated leave durations, resulting in inaccurate day counts. The fix ensures that public holiday dates are properly localized to the company's timezone, leading to accurate leave duration calculations.
Original PR description
Steps to Reproduce: 1. Install the `l10n_in_hr_holidays` module. 2. Enable the "sandwich leave" option for the time off type. 3. Create public holidays that last the entire day, for example from 00:00 to 23:59. 4. Create a leave around the public holiday 5. Duration should be 3 days instead of 1 Cause: When creating a dictionary for company-specific public holidays, the dates from and to are not converted to the company's timezone when calculating the days between public holidays. Fix: To resolve this, the first step is to localize the `date_from` and `date_to` to the company's timezone before counting the days between the public holidays. Task-6012992
A test was failing due to an issue with how the system calculates the initial date for planning features. This fix corrects a time zone calculation error that resulted in an incorrect date being used in the test. This ensures the planning functionality operates correctly across different time zones.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891