Daily updates from Odoo
Thursday, January 29, 2026
43 changes · saas-19.1
Resolved issues and error corrections
This update removes the 'New' button from the DIMONA Declaration List view in the l10n_be_hr_payroll module. This change simplifies the user interface and corrects a minor usability issue, ensuring a cleaner and more straightforward process for generating DIMONA declarations.
Original PR description
. Remove the New button on DIMONA Declaration List view task-5471873
This update increases the width of barcodes on customer receipts generated by the Point of Sale (POS) loyalty program. Previously, the barcodes were too narrow, making them difficult for staff and customers to scan accurately. This change ensures seamless order processing and improved customer experience.
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
This update resolves an error that occurred when users removed the start date on a leave request and then assigned a resource. The fix ensures the system correctly calculates the calendar ID for leave records, regardless of whether a contract start date is present, improving the reliability of leave 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
A bug preventing users from duplicating skills in the HR module has been fixed. This update ensures that users can now successfully create copies of existing skill entries without encountering validation errors. This improves the usability of the skills management feature.
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
A test within the sale_pdf_quote_builder module was failing due to how it handled PDF files. This update replaces the test's invalid PDF data with a real, encrypted PDF, resolving the warning messages and ensuring the test now passes. This improves the stability of the Nightly builds.
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 bug where the Product List page incorrectly kept the last selected category active after a self-order kiosk purchase. The change ensures that the category selection resets upon order confirmation, providing a smoother and more accurate checkout experience for kiosk users. This resolves a potential issue with order accuracy.
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 Forward-Port-Of: odoo/odoo#245830
This update fixes a visual issue where the virtual keyboard would cover the bottom sheet in point of sale, making it difficult for users to see what they were typing. The change ensures the bottom sheet always remains visible by properly resizing the viewport when the keyboard appears. This improves usability and the overall user experience.
Original PR description
Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t…
Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing. This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets. Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?). To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered. Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget opw-5491343 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#244538
This update fixes a technical error that occurred when a user discarded a configurable product while setting up a Point of Sale order. The issue caused a system error, preventing users from completing transactions. The fix ensures the system handles product discard scenarios correctly, improving PoS functionality.
Original PR description
Steps to reproduce: = - Open a PoS with pos_loyalty - Set a customer - Open a configurable product - Click `Discard` button or press `ESC` key Issue: = - A traceback occurs with the error: `TypeError: Cannot read properties of undefined (reading 'product_id')` Reason: = - When a configurable product is discarded during variant selection, the flow continues and attempts to process an undefined product. Fix: = - Ensure if adding a configurable product is discarded while selecting variant it should not p[roccess futher. task-5481204 Forward-Port-Of: odoo/odoo#243996
This update fixes an issue where editing component quantities on the shop floor incorrectly displayed components from all internal locations instead of just the intended source location. The fix ensures that work orders accurately reflect the origin of components, improving inventory accuracy and reducing errors in production.
Original PR description
In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location Steps to reproduce:…
In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location
Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})
Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119
opw-5268989
Forward-Port-Of: odoo/enterprise#102902This update corrects a previous issue where the company flag on customer records was incorrectly determined based solely on the partner's country. Now, the system correctly identifies companies (VKN) based on Turkish tax ID rules (10 or fewer digits) regardless of the partner's location, ensuring compliance with UBL TR e-invoicing requirements. This ensures accurate invoicing and reporting for Turkish businesses.
Original PR description
Currently, the company flag on res.partner is determined based on whether the partner country is Türkiye or not. This causes incorrect behavior for partners using the UBL TR e-invoicing flows, where the company definition must follow Turkish identification rules regardless of the country of origin. This change updates the logic to rely on the invoice_edi_format. When the format is set to ubl_tr. Any partner valid numeric TAX ID with 10 digits or less is set as a company (VKN) and any partner Tax ID with 11 digits or more (TCKN) is set as individual task-5468521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update completes a necessary data upgrade for the Odoo Spreadsheet module. Previously, a client-side data upgrade was missing, which has now been implemented. This ensures data consistency and accuracy within the spreadsheet functionality.
Original PR description
Follow up of 682d6ec1ddb825674999e0db1fc0cc48c3be67c5 where I forgot to add the client-side data upgrade Task-5477426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244935
This update resolves an issue where signed documents sometimes showed incomplete fields before the PDF was fully loaded. By refreshing the sign items after the PDF iframe is ready, the system now consistently displays signed documents with all available fields, improving the user experience.
Original PR description
Ensure sign items are refreshed after the PDF iframe is fully loaded to avoid displaying partially signed documents without fields when not in sign mode. task-5877678 Forward-Port-Of: odoo/enterprise#105533
This update resolves an issue where the 'Accept & Sign' button remained active even when the customer's name field was empty. The fix ensures the button is disabled when no name is entered, preventing users from accidentally proceeding without a valid signature. This improves the user experience and data integrity.
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 update allows users to directly edit the background color of snippets within the s_tabs website builder. Previously, users had to work around this limitation by setting background images/videos. This change also resolves an issue where default background colors couldn't be removed, creating a more intuitive editing experience.
Original PR description
Before this commit, it was not possible to edit the background color of a snippet dropped within the s_tabs snippet. The user could set the background image / video, but not the color. The user could work around the limitation by setting the background color of a snippet, saving it, then dropping it within the s_tabs snippet. Therefore, it made no sense to disable the background color option. Moreover, adding the background color option fixes the reverse issue: if the user dropped a snippet with a background color set by default, they cannot remove it since the colorpicker was not available. Forward-Port-Of: odoo/odoo#245021
The breadcrumb displayed in the Documents section was incorrectly showing 'Unnamed' when accessed through the systray. This update resolves a technical issue where the system couldn't properly identify the active folder, leading to the incorrect display. Now, the breadcrumb accurately reflects the folder name.
Original PR description
When navigating to Documents through the activity menu (systray), the breadcrumb displays "Unnamed" instead of showing the proper folder name. Steps to reproduce: 1. Click the activity menu icon (clock) in the systray 2. Click on "Documents" in the activity dropdown 3. Observe the breadcrumb shows "Unnamed" The issue occurs because when navigating from the systray, the folder section's activeValueId is undefined. This causes getSelectedFolderAndParents() to call folderSection.values.get(undefined), which returns undefined instead of the default folder. Without a valid folder object, the breadcrumb computation has no context and falls back to displaying "Unnamed". The fix ensures that when activeValueId is undefined, we explicitly pass false to values.get(), which correctly retrieves the root/default folder. opw-5473442 Forward-Port-Of: odoo/enterprise#104297
This update resolves a visual issue where the help section within the employee action view was displaying incorrectly (content overlapping). The fix ensures the help content appears correctly in both the main menu and the action itself. This improves the user experience for employees.
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
This update ensures that refusal emails sent to applicants now use the designated 'Send From' email address specified in the recruitment template. Previously, the emails always used the sender's personal email, leading to inconsistent branding. This change improves the applicant experience and ensures a professional communication.
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 update resolves an issue where product attributes and values within the Purchase Product Matrix weren't being translated correctly for partners with different languages. The fix ensures that all product information, including names and values, is displayed in the appropriate language based on the selected vendor contact. This improves the accuracy and usability of the Purchase Order process for international customers.
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 update fixes an issue where negative procurement quantities were not being processed correctly in the MRP system. The change impacts how MTO products are ordered, ensuring accurate quantity adjustments when users reduce product orders. This resolves a discrepancy where the PO quantity was incorrectly showing as 1.
Original PR description
Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a MTO product with a vendor - Create a final product - Create a MO for final product - Confirm MO - Open catalog - Add 0.5 of the MTO…
Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a MTO product with a vendor - Create a final product - Create a MO for final product - Confirm MO - Open catalog - Add 0.5 of the MTO product - Open the linked purchase > Quantity on the PO is 1 Cause ----- The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement). Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves. https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497 In our case, all of the conditions are met: - the quantity update is negative - the move is MTO - `move_orig_ids` is empty, so the `all()` is also true This means the move gets skipped for procurement, although that was not the goal of the commit. Even if we were to fix this last condition, there is also a problem with https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507 that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0. This again does not match the goal of the original commit. ----- Ticket: opw-5440296 Forward-Port-Of: odoo/odoo#245865
This update resolves a visual bug where columns in mass emails weren't rendering correctly when sent. The issue stemmed from a conflict between the email's styling and Odoo's CSS, specifically related to color definitions. The fix ensures consistent column alignment in received emails.
Original PR description
**Steps to reproduce:** - Install Mass Mailing and Website apps - Create a new mailing - Add Columns block with different content size - In "Vert. Alignment" field > Select the "Stretch to Equal Height" option - Columns are properly aligned in Odoo - Save the record and send test mail - The columns are not aligned anymore in the received mail **Issue:** Inline styling breaks in mail engines due to `website.scss` file. The `color-mix` css function is used and cast as a `color()` functional notation in the columns `border-color`. The inline styling is then removed by the mail engine (with all siblings attributes) as it is not compatible with this notation. (e.g. `border-color: color(srgb 0.129412 0.145098 0.160784 / 0.15);`) The color normalization step doesn't take this into account as it only checks for rgb patterns. **Fix:** Overwrite the css with the color notation by a default value for mailing. opw-5225248 Forward-Port-Of: odoo/odoo#242649
This update fixes an issue where event registration emails were incorrectly canceling invitations for contacts on a blacklist. The change bypasses the exclusion list process during email sending, ensuring that all registered contacts receive the intended event information. This improves the reliability of event communication.
Original PR description
**Steps to reproduce:** - Install Events & Contacts apps - Open Contacts - Create a contact "BLACKLIST", email: `blacklist@example.com` - Create a contact "GOOD", email: `good@example.com` - Open Settings > Technical > Discuss > Email Blacklist - Create a record with email: `blacklist@example.com` - Open Events - Create an event - Go to the event attendees - Create attendees for both contacts - Open Settings > Technical > Email > Emails - Both email are listed but the blacklisted one is cancelled **Issue:** The composer created in `EventMailScheduler._send_mail` is using `_process_mail_values_state` to find the list of blacklisted records and applies it to filter the mail recipients, which prevents the event mailing from being processed correctly. **Fix:** `use_exclusion_list` is set to `false` on the composer to bypass its exclusion process. opw-5046491 Forward-Port-Of: odoo/odoo#228445
This update fixes an issue where the Gantt chart controls would overlap the user interface, particularly when using custom date ranges or the Dutch language. The change ensures the controls are displayed correctly, improving usability and preventing visual clutter, especially on smaller screens.
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 | Before | After | |--------|--------| | <img width="736" height="1542" alt="image" src="https://github.com/user-attachments/assets/7c573ab1-fbf8-4f31-83ba-21d66ebc504d" /> | <img width="736" height="1542" alt="image" src="https://github.com/user-attachments/assets/62ab3d47-701e-4e2d-aaef-5c92675236cb" /> | opw-5340869 Forward-Port-Of: odoo/enterprise#105229 Forward-Port-Of: odoo/enterprise#104821
This update resolves a critical issue preventing Odoo payment batches for Swedbank Bankgiros from being accepted. Swedbank requires an 'RfdDocAmt' element in the payment XML, which was missing. This change adds this required field, ensuring successful bankgiro payments.
Original PR description
**PROBLEM** Swedbank requires the RfdDocAmt Element for Bankgiro account. [documentation](https://internetbank.swedbank.se/ConditionsEarchive/download?bankid=1111&id=WEBDOC-PRODE211415244). Payment batches generated by Odoo don't contains this fields, meaning they are refused by the bank. **REPRO STEPS** We can't reproduce the error the client have because it would require a valid bankgiro account. To generate the payment batch xml you have to: 1. Install l10n_se. 2. Create a vendor bank account of type bankgiro. 3. Create a vendor payment with this vendor bank account. 4. Create a batch payment and validate it. 5. There should be a xml in the chatter, you can look at it to see there is no RfdDocAmt element. opw-5427505 Forward-Port-Of: odoo/enterprise#104777
This update fixes an issue where editing a previously edited message could cause incorrect updates due to a mismatch in the message body. The change ensures a reliable comparison of message bodies during editing, preventing data inconsistencies. This improves the overall stability and accuracy of message functionality.
Original PR description
Since #224800, we've been removing the `edited` element from the current message body in order to compare it with the updated body. However, the `edited` element may also be present in the updated body. This change removes the `edited` element from the updated body as well, ensuring a reliable comparison when editing an edited message. Steps to reproduce: - Send a message. - Click `edit`, change the message body and click `save`. - Click `edit` again, don't change the message body this time, then click `save` . - An RPC is made to update the message. Forward-Port-Of: odoo/odoo#245893
This update fixes a bug where users could successfully pay invoices with expired Sales Orders. Now, the system automatically prevents payment attempts when the Sales Order's expiry date has passed, ensuring accurate payment processing and preventing revenue loss. This improves the reliability of our invoicing system.
Original PR description
## Issue: Payment link should expire if payment is expired. #### Steps to reproduce: 1- Create a new quotation. 2- Set the expiry date in the past. 3- Open the action menu and generate a payment link. 4- Open the payment link and pay. Expected result: The payment should fail if the so is expired. opw-5478691 Forward-Port-Of: odoo/odoo#245982 Forward-Port-Of: odoo/odoo#244061
This update resolves an issue where Stripe payments were failing for certain currencies like ISK and UGX. The problem stemmed from a mismatch in how the system converted amounts between the currency used for the payment and the currency expected by Stripe. This fix ensures accurate payment processing across all supported currencies.
Original PR description
### Issue: Stripe payment is failing in some special currencies (e.g. ISK, UGX). ### Steps to reproduce: 1- Configure Stripe 2- Enable ISK currency 3- Create a SO with ISK currency and generate a…
### Issue: Stripe payment is failing in some special currencies (e.g. ISK, UGX). ### Steps to reproduce: 1- Configure Stripe 2- Enable ISK currency 3- Create a SO with ISK currency and generate a payment. 4- Pay using Stripe. The payment will fail due to the amount mismatch. ### Cause: Commit https://github.com/odoo/odoo/commit/9493475273a40320228b92940be15ad8cb0643cb added support for special currency but did not adapt amount validation method in fw. In stripe payload, we are using `const.CURRENCY_DECIMALS` as `arbitrary_decimal_number` to convert the amount to minor currency unit: https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L161-L166 However, we are not using the same constant in conversion back to major currency unit in `compare_notification_data`: https://github.com/odoo/odoo/blob/6e2a29bbb23a8233132dc039d144d97be4feb3af/addons/payment_stripe/models/payment_transaction.py#L393-L395 opw-5871420 Forward-Port-Of: odoo/odoo#245911 Forward-Port-Of: odoo/odoo#245689
This update fixes an issue with the IoT Box's driver download process. Previously, enabling a setting allowed it to download standard drivers, which caused conflicts and duplicated files. Now, the system avoids downloading standard drivers from standard modules to prevent these issues and maintain 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
A bug was preventing users with standard access rights from generating serial numbers for tracked products. This was due to a specific write operation within the system's serial number process. This fix ensures that all users can correctly generate serial numbers, improving inventory management functionality.
Original PR description
**Behavior:** Behavior: When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error. This…
**Behavior:** Behavior: When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error. This happens because there is a write operation on the ir.sequence linked to the serial number at the end of the process that happens only when the 'New' button was previously pressed. And since access rights to ir.sequence are dependant on the base group of the user, changing the user Inventory rights to admin will not resolve the issue. A test has been created to ensure no access error is created when generating sequence numbers as a lower access user, this test would pass without the fix since it is focused on the python function. **Steps to reproduce:** - Create a product that is tracked by serial number - Log in as a user with group_user access (member role) - Go to Inventory -> Operations -> Receipts - Create a new picking and add the product - After clicking on Mark as Todo you'll see Details pop up in the product line - After clicking Details, select Generate Serial/Lots - Click New, then Generate, and you'll get an access error for ir.Sequence opw-5368553 Forward-Port-Of: odoo/odoo#240368
This update fixes a discrepancy in Odoo's Balance Sheet reports for several localized versions (CO, EC, KR, US, and Zambia). It ensures that 'Other Expenses' (expense_other) are now correctly included in the unallocated earnings calculations, aligning with standard reporting practices. This improves the accuracy of financial reporting for these localized businesses.
Original PR description
*= co, ec, kr, us, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's…
*= co, ec, kr, us, zm Currently, the `Other Expense(expense_other)` account type, introduced in saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, even though it's correctly implemented in the standard reports. **Steps to reproduce:** - Install the `l10n_co_reports` and `accountant` modules. - Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet. - Ensure the `report` smart button is set to `Balance Sheet (CO)`. - Equity > Previous Years Unallocated Earnings and click the `info icon`. - Observe the formula of `balance_domain`. **Observation:** The formula does not include the `expense_other` account type. **Root Cause:** After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated Earnings balance domain only in the main `account_reports` module. The corresponding localization reports mentioned above were not updated accordingly, resulting in incomplete Balance Sheet formulas. **Fix:** This commit updates the Balance Sheet report and includes the `expense_other` account type in the Previous Years Unallocated Earnings balance domain, aligning them with the standard reports. [1]: https://github.com/odoo/enterprise/pull/101591 [2]: https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205 opw-5491639 Forward-Port-Of: odoo/enterprise#105838 Forward-Port-Of: odoo/enterprise#105262
This update corrects a technical issue where order documents weren't being properly updated, leading to potential data inconsistencies. The change forces the update of the document's write date, ensuring accurate tracking and reporting within the l10n_mx_edi module. This resolves a previous limitation in the update process.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047 Forward-Port-Of: odoo/enterprise#104859 Forward-Port-Of: odoo/enterprise#103272
This update corrects a technical issue in the Odoo stock module that prevented accurate filtering of stock orderpoints. Previously, the system wasn't correctly restricting records to the current orderpoint, leading to potential inaccuracies. This fix ensures that stock orderpoints are filtered correctly, improving data reliability.
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#246156
Forward-Port-Of: odoo/odoo#242799This update resolves an issue where administrators couldn't view sales order information linked to serial numbers, even when those orders belonged to other users. The fix removes a restriction on access to this data, ensuring all users can see the total number of sales orders associated with a specific serial number. This improves reporting and inventory management.
Original PR description
Steps to reproduce the bug - Create a storable product P1: - Tracking: Serial Number - Log in as Marc Demo - Create a sales order with 1 unit of P1 - Validate the delivery using serial number SN1 -…
Steps to reproduce the bug
- Create a storable product P1:
- Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
- Manage Users
- Mitchell Admin
- Sales: User: own documents only
- Go to the Serial Numbers list view:
- Try to open SN1
**Problem:**
An access error is triggered:
```
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)
Blame the following rules:
- Personal Order Lines
```
When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.
Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.
There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.
**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.
opw-5400731
Forward-Port-Of: odoo/odoo#246009
Forward-Port-Of: odoo/odoo#244570This update fixes a previous issue where the weigh scale displayed incorrect prices due to a lack of consideration for pricelists and fiscal positions. Now, the weigh scale accurately reflects the price, including any adjustments defined in a customer's pricelist or fiscal position, ensuring accurate sales transactions.
Original PR description
Before this commit, the pricelist and fiscal position where not taken into account when displaying the price on the weigh scale. This caused confusion when selling products with pricelists or fiscal positions that modified the price. opw-5456144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243260
This update fixes an issue where the weigh scale displayed incorrect prices due to a lack of consideration for pricelists and fiscal positions. Now, the weigh scale accurately reflects the price based on the customer's selected pricelist or fiscal position, improving sales accuracy and customer satisfaction.
Original PR description
Before this commit, the pricelist and fiscal position where not taken into account when displaying the price on the weigh scale. This caused confusion when selling products with pricelists or fiscal positions that modified the price. opw-5456144
This update fixes an issue where the product quantity and unit of measure fields on the MRP production kanban cards would become unreadable when product names were long. The change ensures these fields remain consistently visible regardless of product name length, improving usability and clarity.
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
This update resolves a minor technical issue within the l10n_jo_hr_payroll module. A typographical error in the module's manifest file has been corrected. This ensures the module functions correctly and integrates smoothly with the Odoo system.
Original PR description
Fix some typos in the manifest of the module. Task: 5462506
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 reliable printer connectivity. This prevents connection failures and improves the overall printing experience.
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#246151
Forward-Port-Of: odoo/odoo#245910This update resolves an issue where Mexican CFDI invoices generated with Solution Factible were being rejected due to incorrect exchange rate precision. The fix applies a rounding adjustment previously implemented for other PACs, ensuring invoices with larger payment values are now processed correctly. This prevents invoice rejection and ensures compliance with Mexican tax regulations.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#105102 Forward-Port-Of: odoo/enterprise#102557
This update optimizes how Odoo builds SQL queries when joining related models with delegated access. Previously, joining on fields with delegated access required extra permissions, which is now bypassed. This change improves query performance and ensures consistent access control, particularly when using search functionality.
Original PR description
When building the SQL for a related field, we join the table for the comodel and may apply user access to that comodel. Using *inherits* already adds record rules for that field, so joining on the field on which "delegates" access to fields, can be done without additional permissions.
```py
class M1(Model): ...
class M2(Model):
_inherits = {'m1': 'm1_id'}
m1_id = fields.Many2one(...)
```
Consider the following, `Query(m2_record).m1_id` should join without additional access rules. This is fine because the query usually comes from a `_search` (which has added the necessary permissions).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where dialog windows were hidden behind the AI chat window, making them difficult to use. Now, the AI chat window remains consistently above all other dialogs, ensuring a clearer and more intuitive user experience for interacting with the system.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Dialogs were rendered behind chat windows, making them difficult to see and interact with. **Current behavior before PR:** --------------------------------- - The dialog appears behind the chat window **Desired behavior after PR is merged:** ----------------------------------------- - Dialogs are displayed above all chat windows except AI - The AI chat window remains intentionally above dialogs **Task:** 5367135 Forward-Port-Of: odoo/enterprise#105710 Forward-Port-Of: odoo/enterprise#103076
This update fixes a previous issue where the VoIP ringtone would play incorrectly due to multiple tabs receiving notifications. Now, a central SharedWorker determines the best tab to play the ringtone, ensuring only one ringtone plays at a time and addressing potential reliability problems like connection loss or throttling.
Original PR description
Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being…
Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution. However, we were informed that sometimes the call wouldn't ring at all 🤬 This called the reliability of the system into question. What would happen if: - The main tab loses the WebSocket connection? - The main tab is throttled? - The main tab was never interacted with, preventing us from playing audio? - The notification arrives after the main tab is killed and before a new main tab is elected? This commit attempts a new approach ⋆✴︎˚｡⋆ All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone. This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that: - effectively received the incoming call notification - is allowed to play audio [Task-5411760](https://www.odoo.com/odoo/project.task/5411760) Backport of https://github.com/odoo/enterprise/pull/104885 Forward-Port-Of: odoo/enterprise#105022
This update fixes an issue where changes to form fields weren't immediately reflected in the builder interface. By moving key properties to the component and using a state management system, the builder now correctly updates when field types or settings are modified, ensuring a more responsive and accurate editing experience.
Original PR description
*: website After the [refactoring of html_builder], containers weren't updated all the time properly. They were updated only when the options' length or ids, respectively, have been changed, which is not the desired behavior. For example, if `isCloneDisabledReason` changes, we won't be able to see the changes right away. That's why we moved some options containers' props to the component to use `useDomState`. Steps to see the issue: - Open website and start editing - Drop a form - Add a field and click on it - Change its type to one of the existing fields, e.g. 'Alias Domain' => The duplicate button of the builder is not deactivated, while it should be. The issue exists vice versa too (when we change the type from an existing field to a custom one). [refactoring of html_builder]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5391316 Forward-Port-Of: odoo/odoo#246150 Forward-Port-Of: odoo/odoo#239235
This update fixes an issue where optional products for a sale order were always added at the end of the order, regardless of where the main product was placed. The change ensures that optional products are now correctly inserted immediately after their corresponding main product line, creating a cleaner and more organized sale order view. This improves the user experience and data clarity.
Original PR description
# Steps to reproduce: * Create a sale order with two sections * In the first section, use the ellipsis to add a product that has optional products configured and add its optional products * The optional product lines are added under the next section instead of the current one # Issue: * Optional products are always appended at the end of the order, even when the main product is inserted in the middle # Cause: * While creating new lines in `sale_product_field.js`, the intended insertion position is ignored # Solution: * Update the configurator save logic to insert optional product lines immediately after their corresponding main product line Affected Version-19.0 opw-5445800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243069