Wednesday, January 28, 2026
18 changes · saas-18.4
Resolved issues and error corrections
Sales orders using the DIN 5008 layout now show the Delivery Date on both printed reports and customer preview pages. This ensures customers and sales teams see the expected delivery information consistently before and after printing.
Original PR description
**Steps to reproduce:** 1. Install modules `sale_management` and `l10n_din5008_sale` 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a…
**Steps to reproduce:** 1. Install modules `sale_management` and `l10n_din5008_sale` 2. Go to Settings, Configure Document Layout and set layout to DIN 5008 3. Create a new Sale Order 4. Set a customer, add a product, and fill in the Delivery Date (Other Info) 5. Click on Print and Preview **Issue:** The Delivery Date (commitment_date) is not displayed on: - The DIN 5008 sale order report - The sale order preview (portal view) Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout. **Cause:** The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view. **Solution:** This commit adds the Delivery Date information to: - The DIN 5008 sale order report template - The sale order portal/preview view **opw-5490651** **Before:** <img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" /> <img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" /> **After:** <img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" /> <img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" /> Forward-Port-Of: odoo/odoo#244917
This fix prevents Chilean invoices from being confirmed with document numbers that contain non-numeric characters. It avoids a system error during confirmation and helps ensure invoice folio numbers comply with Chilean tax authority requirements.
Original PR description
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits. Steps to replicate: - Install…
An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.
Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.
Error:
```
File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
res = super().action_post()
File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
self._post(soft=False)
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
move._l10n_cl_create_dte()
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```
Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.
Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.
Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.
[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8
No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#241505This fix prevents repair orders from crashing when users update the scheduled date while a parts line is missing a selected product. It makes the Repairs workflow more reliable by safely handling incomplete part lines during normal editing.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error. Forward-Port-Of: odoo/odoo#244179
This fix makes the automated manufacturing order checks wait until product filtering and quantity updates are fully applied. It helps avoid false test failures and improves confidence that component quantities are handled correctly.
Original PR description
Error message ----- ``` FAIL: TestTourMrpOrder.test_mrp_multi_step_product_catalog_component_transfer Traceback (most recent call last): File "/data/build/odoo/addons/mrp/tests/test_order.py", line…
Error message
-----
```
FAIL: TestTourMrpOrder.test_mrp_multi_step_product_catalog_component_transfer
Traceback (most recent call last):
File "/data/build/odoo/addons/mrp/tests/test_order.py", line 5433, in test_mrp_multi_step_product_catalog_component_transfer
self.assertEqual(component_transfer.product_uom_qty, 2)
AssertionError: 1.0 != 2
```
Cause
-----
It looks like somehow one of the 2 clicks on the product is either not registered, or the update of the POL's quantity isn't triggered / doesn't happen fast enough, so the tour ends with a quantity of 1 for the product. I see 2 possible causes for this:
1. The product is visible in the initial view. So when the view updates (because of the filtering step), the next step - clicking on the product - the clicks can already be triggered, which might lead to an inconsistent state.
2. There is some synchronicity issue with the quantity update's debounce
https://github.com/odoo/odoo/blob/11292070870ef22663364eda5a4b243dea68856a/addons/product/static/src/product_catalog/kanban_record.js#L16-L18
Solution
-----
Add extra steps to wait for filtering to be applied. Also add extra steps to ensure correct update of the POL's quantity.
-----
Runbot error 237956
Forward-Port-Of: odoo/odoo#243974This fixes a visual issue in the website builder where connector lines between related settings could appear broken when an option included sub-options. The settings panel now looks cleaner and easier to follow when configuring background image options.
Original PR description
Steps to reproduce: - Open the website builder and drop a "Cover" snippet on the page. - In "Background > Image", choose "Position: Repeat pattern" to reveal the "Width/Height" sub-options. - Issue: the vertical connector line between the "Filter" and "Position" options is broken. After this commit, the gap is removed. Options at the same level are now properly connected, even when one of them contains sub-options. task-5155955 | Before | After | | ------------- | ------------- | | <img width="286" height="424" alt="image" src="https://github.com/user-attachments/assets/db035598-5094-4ec3-a42b-dc86bd871b9b" /> | <img width="285" height="422" alt="image" src="https://github.com/user-attachments/assets/d0229c5b-d3ea-41a2-9ed7-6155fc34d280" /> |
The Payments list filter for “Not Sent” now correctly identifies payments that have not been sent. This helps accounting users quickly find pending customer or vendor payments without seeing empty or inaccurate results.
Original PR description
The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view. This commit updates the filter logic to properly…
The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view. This commit updates the filter logic to properly identify payments that haven't been processed or sent, ensuring the filter displays the correct records to the user. **Description of the issue/feature this PR addresses:** This PR fixes a bug in the "Not Sent" search filter within the Payment views (Account Payments). Currently, the filter fails to accurately identify and display records that have not been sent, leading to an empty or incorrect list of results regardless of the sending payment's actual status. **Current behavior before PR:** When a user applies the "Not Sent" filter in the Payments list view (including both Customer and Vendor payments), the system returns incorrect records or no records at all. This is caused by an inconsistent domain definition that doesn't align with the internal field tracking the "sent" status of the payment. **Desired behavior after PR is merged:** The "Not Sent" filter will correctly filter the list to show only those payments where the "Sent" status is not True. This will provide users with an accurate view of pending actions for both Customer and Vendor payments, ensuring consistency across the accounting module. **Steps to reproduce:** 1. Navigate to the Accounting (or Invoicing) module. 2. Go to Vendors > Payments or Customers > Payments (the issue is global). 3. Ensure there are several payments in the list, some marked as "Sent" and others not yet sent. 4. Click on the Filters dropdown menu in the search bar. 5. Select the "Not Sent" filter. 6. Observe the results: Notice that the list either becomes empty or continues to show records that do not match the "Not Sent" criteria, failing to filter the data correctly. **video** https://drive.google.com/file/d/1NTKQ1tHWyZWfs3CPolfDTOMrqaDD9OcN/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245487
This fixes guided tour pointers so they only appear when their related page element is currently accessible. It prevents distracting tour hints from showing on top of unrelated pop-up windows, creating a cleaner user experience.
Original PR description
POC for task-5490670 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 Forward-Port-Of: odoo/odoo#245838 Forward-Port-Of: odoo/odoo#243852
Visitors and guests in live chat will no longer see internal chat commands such as help or leave that are not available to them. This reduces confusion and keeps the chat interface focused on actions visitors can actually use.
Original PR description
**Current behavior before PR:** channel commands like `/help ` or `/leave` are visible to visitors even it is not functional for them. **Desired behavior after PR is merged:** commands are now hidden from visitors. task-4552209 related: [PR](https://github.com/odoo/enterprise/pull/82963) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245171 Forward-Port-Of: odoo/odoo#196737
Saved carousel snippets now display at their natural height in the snippet dialog instead of being cut off by a fixed preview size. This helps users recognize and reuse custom carousel snippets accurately, especially when slides contain taller content.
Original PR description
Steps to reproduce: - Drag and drop a Carousel. - Add content to the first slide of the carousel to make the snippet taller. - Save the snippet as a custom snippet. - Open the snippet dialog. - Issue: The height of the preview for the saved snippet is forced to 550px, causing the snippet to be truncated. After this commit, the height is no longer forced; it now adapts to the snippet content. task-5156137 Forward-Port-Of: odoo/odoo#244251
The scale selector now behaves better on narrow mobile-sized screens when long translated date ranges are shown. This prevents Gantt view controls from covering each other, making project planning easier to use in languages like Dutch.
Original PR description
Steps to reproduce ================== - Switch to dutch - Emulate an iPhone SE viewport in the browser settings - Open a project - Switch to the gantt view - Use a custom date range -> The gantt controls are displayed on top due to the daterange format being to long Note ==== The fix is in the ViewScaleSelector component, but only the gantt view uses a custom scale opw-5340869 Forward-Port-Of: odoo/odoo#245552
Odoo now shortens overly long printer identifiers before adding them to CUPS. This prevents setup failures for printers whose network names or device addresses exceed CUPS limits, improving reliability for IoT printing.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#245910Applicant refusal emails now respect the sender address configured on the chosen email template. This helps recruitment teams send consistent, branded communications instead of always using the individual user's email address.
Original PR description
### Issue: When refusing an application, the system will always use the user's email to send the refusal, even if the template specifies an email to send from. ### Steps to reproduce: - Recruitment > Configuration > Refuse Reasons - Go to one of their template (i.e. "Recruitment: Refuse") - in Settings add a "Send From" email - Recruitment > Applications, click on an application - Click "Refuse" - Select the refuse reason with the template - Refuse - The mail is sent with the user email ### Cause: `_prepare_mail_values()` only returns `self.env.user.email_formatted`. ### Solution: If there is a template with `email_from`, we use this, otherwise `self.env.user.email_formatted` opw-5356662
This fix restores the intended quantity check used during purchase stock valuation. It prevents the system from treating the condition as always true, helping keep purchase and manufacturing stock valuation behavior accurate.
Original PR description
During the changes made in #192123 to use the float utils directly from the `uom.uom` rather than importing the float utils, this line was mistakingly changed. With that change, the condition would always be truthy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures stock replenishment rules are only applied to the intended records when they are deleted or processed. It prevents the system from silently ignoring a filter, reducing the risk of unintended stock rule behavior.
Original PR description
Description of the issue/feature this PR addresses:
This PR fixes an incorrect domain construction when restricting records to the current recordset.
The existing code attempted to combine domains using expression.AND() but did not apply the result, and referenced an invalid domain field.
Current behavior before PR:
- expression.AND() was called without assigning its return value, so the combined domain was never applied.
- The domain condition used ('ids', 'in', self.ids), which is not a valid searchable field.
- As a result, the intended filtering by the current recordset was silently ignored.
Desired behavior after PR is merged:
- The domain is correctly rebuilt and assigned using expression.AND().
- The filter uses the valid field instead of ids
- Records are properly restricted to the current recordset
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242799This update hides live chat commands (like `/help`) from website visitors and guests. Previously, these commands were visible, potentially leading to confusion or misuse. This change enhances website security and the user experience for standard visitors.
Original PR description
**Before PR:** channel commands like `/help ` or `/leave` and more are visible to visitors or guest even it is not functional for them. **After PR:** all commands are now hidden from visitors/guests. task-4548666 Forward-Port-Of: odoo/enterprise#105133 Forward-Port-Of: odoo/enterprise#82963
This update ensures that sign templates created in languages other than English automatically use the correct document name. Previously, templates defaulted to 'New Template' regardless of the selected language. This fix corrects a translation issue, guaranteeing accurate template naming across all supported languages.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#92682
This update resolves an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and outdated versions. A new setting allows custom drivers to be downloaded, but this change has been adjusted to avoid overwriting existing drivers and introducing previous bugs. This ensures a more stable and reliable IoT Box experience.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105686 Forward-Port-Of: odoo/enterprise#105531
A recent bug in the Point of Sale appointment tour was causing it to fail when tests were run close to midnight. This was due to the system scheduling appointments for the next day, which the POS frontend then filtered out. This fix ensures the tour functions correctly regardless of the time of day.
Original PR description
The `test_pos_restaurant_appointment_tour_basic` test was failing when run late in the day. The test creates an appointment 30 minutes in the future and expects a corresponding label to appear underneath the table in the POS floor plan. However, if the test is executed near midnight (e.g. 23:45 UTC), the appointment is scheduled for the following day. Since the Point of Sale frontend only displays appointments for the current day, it filters the booking out, causing the tour to timeout while waiting for the label. runbot-232601 Forward-Port-Of: odoo/enterprise#105738