Thursday, January 29, 2026
23 changes · 19.0
Resolved issues and error corrections
After a customer confirms an order in self-order kiosk mode, the product list now returns to its default category view instead of keeping the last selected category. This makes the next customer's ordering experience clearer and reduces confusion at shared kiosks.
Original PR description
The Product List page was keeping the previously selected category active after checkout in kiosk mode. This commit resets the category selection on order confirmation. Task-5877912
Loyalty coupon barcodes printed on Point of Sale receipts are now wider. This makes next-order coupons easier for scanners to read, reducing checkout friction when customers redeem them.
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="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </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#244353 Forward-Port-Of: odoo/odoo#242469
The sales order signature flow now keeps the Accept & Sign button disabled when the Full Name field is blank or only contains spaces. This prevents customers from accidentally submitting an unsigned or invalid acceptance during the sign-and-pay process.
Original PR description
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains…
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains enabled even when the Full Name field is empty. **Root cause:** - At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided - Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled. **Solution:** - If the cleaned name is empty or contains only spaces, do not generate image. - Instead, immediately clear the signature pad so the button remains disabled. [1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109 **Before:** <img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" /> **After:** <img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" /> **opw-5361890** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238638
This fix prevents an error when creating or editing resource time off without a start date and assigning it to an employee with an active contract. It also keeps the working calendar correctly aligned when the resource or start date changes, improving reliability for HR scheduling.
Original PR description
Currently, an error occurs when user sets the resource on a resource leave. **Steps to Reproduce:** - Install `hr_contract` with demo data. - Go to `Resource Time Off`. - Create a new record and…
Currently, an error occurs when user sets the resource on a resource leave. **Steps to Reproduce:** - Install `hr_contract` with demo data. - Go to `Resource Time Off`. - Create a new record and remove the `start date` value. - Select the `Anita Oliver` resource `(employee record with running contract)`. **Error:** `TypeError: '<=' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** This error occurs when the user removes the start date and sets a resource that is linked to an employee with a contract. In this case, the system groups leave records based on the contract [1], and while computing calendar_id for the leave, it filters records by checking whether the leave start date falls between the contract start and end dates [2]. Since the leave start date is False, the comparison raises the error. Another issue is that when the user changes the start date, the calendar_id should be updated based on the employee’s current contract. **Fix:** This commit ensures that when setting or changing the resource_id, for contracts with and without a start date, the calendar_id is computed correctly. [1]: https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L17 [2]- https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/hr_contract/models/resource_calendar_leaves.py#L29 **No Task ID** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244372 Forward-Port-Of: odoo/odoo#241638
Users can now duplicate employee skills without running into a validation error. This makes managing and reusing skill records smoother for HR teams.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Install the hr_skills module - Go to the Skills menu - Select a skill and click Duplicate Issue: - A validation error appears when duplicating a skill Solution: - Updated the copy_data method so skills can be duplicated without causing a validation error Task - 5481185 Forward-Port-Of: odoo/odoo#243227
This update fixes an internal test for the PDF quote builder by using a realistic encrypted PDF file instead of placeholder data. It prevents unnecessary PDF parser warnings during automated builds, improving test reliability without changing customer-facing behavior.
Original PR description
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to…
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to reproduce:** - Install `sale_pdf_quote_builder` module. - Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed). - Observe `PyPDF` warnings in the logs. **Warnings:** ``` WARNING server pypdf._reader:435 invalid pdf header: b'test' WARNING server pypdf._reader:435 EOF marker not found WARNING server pypdf._reader:435 EOF marker not found ``` **Root cause:** Odoo officially supports the PyPDF version defined in requirements.txt [1]. The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when parsing arbitrary byte content. Because the test uses raw bytes instead of a structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings. **Fix:** This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2]. This commit fixes test failures caused by [3]. **Note:** Refer to [4] for generating the encrypted file. [1]: https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65 [2]: https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75 [3]: https://github.com/odoo/odoo/pull/230712 [4]: https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV runbot-238399 Forward-Port-Of: odoo/odoo#246034
This update corrects a formatting issue in call-related actions within Odoo Discuss. It helps ensure users see clearer, properly displayed call controls or messages, reducing confusion during communication workflows.
Original PR description
Introduced by odoo#236297 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue in the Employees area where help text could overlap when viewing the employee action in debug mode. The help content now appears correctly in both the Employees menu and the related action view, improving readability for users and administrators.
Original PR description
While performing a task I observed an improper view in employees action. Steps to Reproduce : 1. Activate debug mode and go to Employees/Employees/Employees menu 2. Go to its action 3. You will see improper view(content overlapping) in help section. These changes were added [here](https://github.com/odoo/odoo/pull/214810/changes#diff-99eff1b023601f0f844a2fa7efc6c4e62e13a8592d5b799113f848ac4c7565f8L549-R658 ). I have made the changes accordingly so that the Help content looks fine in both Employees menu and action. before : <img width="1695" height="752" alt="image" src="https://github.com/user-attachments/assets/6a847373-5ac2-4877-a07f-ad58338429c5" /> after : <img width="1272" height="823" alt="image" src="https://github.com/user-attachments/assets/16b50843-e736-490a-8a00-44848c6011fa" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244651
When recruiters refuse an application, Odoo now respects the sender address set on the refusal email template instead of always using the current user's email. This helps recruitment teams keep candidate communications consistent and aligned with their chosen company or department mailbox.
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 Forward-Port-Of: odoo/odoo#245937
This change downgrades certain Gmail and Outlook connection request failures from errors to warnings in system logs. Users already receive the appropriate message when these issues occur, so this helps reduce unnecessary error alerts while keeping the issue visible for monitoring.
Original PR description
*=mircosoft_outlook Currently the logger records an error in the logs whenever an IAP request encounters an error. Error: `Can not contact IAP: <!doctype html>` Since this is a request-related error, the user receives an appropriate message when this type of error occurs, so Therefore, it is better to log this as a warning rather than an error. sentry-6992264566
Purchase orders now show product attribute names and values in the vendor's language when products use variants that are never created. This prevents confusing untranslated text on purchasing documents and improves clarity for multilingual vendor relationships.
Original PR description
When adding a product with never variant, their name and values are not translated in the language of the partner. ### Steps to reproduce: * Activate the setting Variants and Variant Grid Entry. *…
When adding a product with never variant, their name and values are not translated in the language of the partner. ### Steps to reproduce: * Activate the setting Variants and Variant Grid Entry. * Create a product , add a translation for its name. * Create a attribute and a translation for its name, with variant creation set to never. * Create values for the attribute and add translation for their name. * Add the attribute and it's values to the product . * Create a contact and change it's language to the language of the translation. * Create a purchase order set the contact as the vendor * Add the product, and set the grid number to 1 -> the attribute and attribute value is not translated. ### Observation: When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product: https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288 But in case of never attribute, the name it retrieved after and we don't set the context: https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174 -> we retrieve the information but in the wrong language opw-5396058 Forward-Port-Of: odoo/odoo#242692
This fix prevents IoT printer setup from failing when a discovered printer has an unusually long name. Odoo now shortens the printer identifier to fit the CUPS limit, improving reliability for supported printing devices.
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#246077
Forward-Port-Of: odoo/odoo#245910This fixes an error that could occur during upgrades when purchase order lines are down payments and do not have a unit of measure set. The change helps upgrades run more reliably without interrupting purchase-related data processing.
Original PR description
…duct UoM According to the constraint `_accountable_required_fields`, the field `product_uom_id` is not required when `display_type` is set or when the line is a downpayment. The first case has been patched, but not the second, which can lead to errors during upgrades. ``` ValueError: Expected singleton: uom.uom() ```
This fixes an error when setting up Peppol in demo mode for a branch company that shares the same VAT number as its parent. Demo setups now avoid reusing the same client identifier, so users can test branch-company Peppol flows without being blocked.
Original PR description
Steps to reproduce in demo: 1. Activate Peppol in the main company for both sending and receiving; 2. Create a branch company (with same VAT number as the main company); 3. Activate Peppol in the branch and select "Send from parent company"; 4. Error message: "This id_client is already used on another user.". In demo edi_mode, when trying to connect a branch company with the same VAT than the parent company, the demo function took the same id_client for every company, which violates the unique constraint on id_client. task-5888203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The recruitment stage previously called "Initial Qualification" is now labeled "Qualification." This small wording change makes the hiring pipeline label shorter and clearer for users without changing any workflow behavior.
Original PR description
This is a small follow-up PR to the original PR to simply rename a stage label. See https://github.com/odoo/enterprise/pull/105278 Task-ID: 5454691
The website editor now hides the delayed-translation notification when a user enters edit mode. This prevents the pop-up from covering editing controls, making multilingual website updates smoother and less confusing.
Original PR description
When we have a delayed translation, we get a notification saying that we should edit, or translate to apply the changes made in the default language. However, when we click on edit, the notification is still present, and it blocks the dropdown, so the user doesn't see it until the notification disappears. Steps to see the issue: - In a multilingual websites: - Add a content in the default language, 'A' - Translate the content in your other language 'B' - Come back to 'A', and edit the content, e. g. add some style - Come back to the language 'B' => A toaster notification appears, and if you click on "Edit" button, you cannot see what's below. task-5447519
Manufacturing order cards now keep quantity and unit fields readable even when product names are very long. This improves day-to-day visibility for production teams using the kanban view without changing workflows.
Original PR description
Description of the issue/feature this PR addresses: On MRP production kanban, if the name of the product is too long, `product_qty` and `product_uom_id` fields on the card shrink and become unreadable. This adds proper classes to keep those fields from shrinking no matter how long product's name is. Current behavior before PR: <img width="1561" height="303" alt="image" src="https://github.com/user-attachments/assets/08e299be-c6e2-4241-b289-aaa2fab9a94f" /> Desired behavior after PR is merged: - The size of the product's name should be fine no matter how long the name of the product is. - The `product_qty` and `product_uom_id` should not shrink if the name of the product is long. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245861
A recent issue in the Point of Sale system's appointment tour was triggered when tests were run close to midnight. The system incorrectly filtered out appointments scheduled for the next day, causing the tour to fail. This fix ensures the tour functions correctly regardless of the time of day the test is executed.
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
This update changes how errors during Shopee order synchronization are handled. Instead of causing an exception and a log error, the system now logs a warning. This prevents unnecessary disruptions for users who have already received email notifications about these issues, streamlining the logging process.
Original PR description
Currently a logger exception is printed in the log when an error is generated during the synchronization of Shopee shop orders. Since this is not a blocking error and the user has already been notified about this error via email, it is idle for the user to log a warning instead of logging an exception here. sentry-7122935675
This update resolves an issue where the IoT Box was incorrectly downloading standard drivers, leading to potential conflicts and duplicated files. To allow custom driver development, a checkbox was added, but this caused problems with existing drivers. The fix now avoids downloading standard drivers from modules to ensure stability.
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#105770 Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue with how employer social insurance contributions are recorded in Odoo Enterprise for Saudi Arabia. The change ensures that these payments are accurately assigned to the correct accounting accounts, improving financial reporting and compliance. This resolves a previous error impacting payroll processing.
Original PR description
Fix the account configuration used by Saudi social insurance contribution salary rules for the company. This ensures employer contributions are posted to the correct accounting accounts. Task-5468575
This update clarifies the recruitment process by renaming a stage label in the 'Initial Qualification' stage to 'Qualification' within the Enterprise module. This change improves the clarity and consistency of the recruitment dashboard, making it easier for users to understand the stages of the hiring process. It's a minor adjustment to enhance the user experience.
Original PR description
This is a small follow-up PR to the original PR to simply rename a stage label. See https://github.com/odoo/enterprise/pull/105278 Task-ID: 5454691
This update resolves an issue where embedded actions within documents were disappearing from the folder's action list, preventing users from managing or deleting them. The fix ensures that embedded child actions remain visible and accessible, streamlining the document management process.
Original PR description
Server actions that were standalone (not a child) and embedded onto a documents folder cannot be executed anymore when they are linked to a parent action. Before saas-18.3, the embedded child action…
Server actions that were standalone (not a child) and embedded onto a documents folder cannot be executed anymore when they are linked to a parent action. Before saas-18.3, the embedded child action would still be in the documents' available_embedded_actions, and couldn't be removed, such that a fix was necessary. From saas-18.3 onwards, children embedded actions are no longer visible. As this precise case wasn't explicitly tested, we continue the FW-port with the (adapted) test. Furthermore, we add a garbage collection of the embedded actions for children actions, as they cannot be executed anymore. Initial FIX: ### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#105235 Forward-Port-Of: odoo/enterprise#100395