Wednesday, January 28, 2026
9 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue that prevented users from scheduling repairs when a product wasn't assigned to a repair move line. The fix addresses a calculation error triggered by updating the scheduled date, ensuring repairs can be properly scheduled without causing system failures. This improves the reliability of the Repairs module.
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 update increases the width of the barcode printed on customer receipts generated through the Point of Sale (POS) loyalty program. Previously, the barcode was too narrow, causing scanning difficulties. This change ensures receipts can be reliably scanned, improving the customer experience and order processing efficiency.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="441" height="557" alt="image" src="https://github.com/user-attachments/assets/658ee8dd-a4d5-4b2d-a12d-5ebd8db48c9d" /> </td> <td> <img width="447" height="569" alt="image" src="https://github.com/user-attachments/assets/59a2282b-8da7-4576-9dd1-edd787cd9314" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242469
This update fixes an issue where the Odoo tour pointer was appearing in unwanted locations, like above dialogs. Now, the pointer only shows if it's directly linked to the element being interacted with, creating a cleaner and more focused user experience. This improves the overall usability of the onboarding tour.
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
A recent issue with the Point of Sale appointment tour was resolved. The test environment was scheduling appointments for the next day, causing the tour to fail when run near midnight. This fix ensures the tour functions correctly by addressing the scheduling discrepancy.
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
This update fixes an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and reintroducing previous problems. To allow custom driver development, a checkbox was added, but this created a risk of overwriting existing drivers. Now, the system avoids downloading standard drivers to ensure stability and prevent issues.
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#105634 Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue where new CRM contacts created via quick create didn't automatically inherit the address of the associated company. The fix ensures that company address information is correctly applied during contact creation, improving data accuracy and consistency within the CRM.
Original PR description
**Steps to reproduce:** - Install Sales/CRM apps - Go to CRM app - Create new opportunity card - Set a company (`commercial_partner_id`) - Create a new contact using `quick_create` - The new contact is linked to the company but it doesn't inherit the company address **Issue:** Kanban quick create of crm app was modified to allow a company field, which is used as `default_parent_id` when creating a new partner from the card. This properly set the partner `parent_id` and `commercial_partner_id` but without applying the logic of `_fields_sync()` which also added the address (only for quick_create). **Fix:** Use `_add_missing_default_values` to check if a default value was given for `parent_id` in `_fields_sync()`. related: https://github.com/odoo/odoo/commit/a6c3ebc21c066ab4d5711f535ca5fc858e6485b0 opw-4932114
This update resolves an issue where Odoo couldn't connect to printers with overly long device names. The fix automatically shortens these names to comply with CUPS's 127-character limit, ensuring consistent printer functionality. This prevents connection errors and improves printer availability.
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#245910This update fixes a visual issue where the Gantt chart's date range controls would overlap with the user interface, particularly when using custom date ranges in Dutch on smaller screens. The fix ensures the Gantt controls are displayed correctly, improving usability and preventing a confusing user experience. This resolves a reported problem impacting the Gantt chart functionality.
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
This update fixes a technical issue in the stock orderpoint module that prevented accurate filtering of records based on the current orderpoint. The fix ensures that the system correctly restricts records to the current orderpoint, improving data accuracy and efficiency. This resolves a silent error that could have impacted orderpoint management.
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#242799