Daily updates from Odoo
Tuesday, July 8, 2025
29 changes · saas-18.4
Resolved issues and error corrections
This fixes an issue where text entered in the website builder, such as “<br>”, could be incorrectly changed when saving translations, blog titles, or reusable blocks. Users can now save literal text with special characters without it turning into the wrong display or HTML behavior.
Original PR description
> 65. Special character written in translation are being converted into HTML Entity name like `<br> => <br>`
Copying a manufacturing bill of materials now correctly links by-products to the copied operation instead of the original one. This prevents confusion or incorrect production setup when teams duplicate manufacturing recipes that include operations and by-products.
Original PR description
### Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. ### Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom #### > The copied by product line refer to the operation of the original bom this can be checked by archiving the copied operation which should erase its link with the copied by product line but will not ### Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217319 Forward-Port-Of: odoo/odoo#216609
This update applies follow-up corrections requested after an earlier merge, focused on demo data used in accounting and Belgian localization. It helps keep sample setups accurate and consistent for testing, demonstrations, and onboarding scenarios.
Original PR description
After [this PR](https://github.com/odoo/odoo/pull/209628) was merged, a few last comments were made, this commit includes the changes suggested in those comments. --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216815
This fix prevents a website image hover effect from being destroyed more than once. It helps avoid unnecessary errors during page interactions, improving reliability for visitors and editors.
Original PR description
In case the interaction is destroyed, we should not try to destroy it again. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an Inventory issue where reception reports and labels were downloaded as PDFs instead of being sent to the assigned IoT printer. The system now retrieves the proper report setup from the server, so warehouse teams can print reception documents through their configured devices as expected.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217693 Forward-Port-Of: odoo/odoo#215887
The settings help text for intercompany rules was corrected to say that vendor bills are created, not invoices. This avoids misleading users when configuring intercompany transactions.
Original PR description
This commit: https://github.com/odoo/odoo/commit/e2a0c6edb8c9c1fd0aba2f92f9187678e68971a9 change a help in the intercompany rules. The help sentence is wrong since we don't create invoice but bills. task-4907810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217275
Point of Sale receipts now show the cashier who is active when the order is paid, rather than the cashier first assigned to the order. This prevents incorrect staff attribution on receipts when the cashier is changed during payment.
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 Forward-Port-Of: odoo/odoo#216339 Forward-Port-Of: odoo/odoo#215543
This fixes an upgrade issue where empty text filter defaults in spreadsheets were treated as actual filter values. After the change, empty defaults are correctly recognized as no default value, preventing unintended filters after upgrading.
Original PR description
The upgrade script from saas-18.3 to saas-18.4 converting the default value of text filter is wrong. It didn't account for the empty string which should be considered as "no default value" `defaultValue: "hello"` --> `defaultValue: ["hello"]` correct `defaultValue: ""` --> `defaultValue: [""]` not correct Task: 4926326 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated test for website color customization so it waits correctly for background updates to finish. It helps keep website editing quality checks stable and reduces false failures during release validation.
Original PR description
Waiting an animationFrame after each click (fix done in [1]) was not sufficient, we actually need to wait for 2 or 3 separate ticks depending on the case, because `customizeWebsiteColors` calls between 2 and 3 debounced functions (`debouncedSCSSColorsCusto`, possibly `debouncedSCSSVariablesCusto`, and finally `reloadBundles`) with a 0-ms delay. [1]: https://github.com/odoo/odoo/commit/cbcd1b142e2a1c6a245fa8a993ecc8ebd72eece4 runbot-229604 runbot-229686
Fixed a Point of Sale loyalty issue where refunding an order paid with reward points could deduct those points a second time. Refund transactions now avoid recharging loyalty points, preventing customers from unfairly losing rewards.
Original PR description
**Problem:** When refunding an order that has been paid using a reward system, the points are deducted again as if the client made another purchase using those points. This means that in the case of a refund, the client would not only lose those points but have to spend them again. **Steps to reproduce:** - Make a purchase in POS using a reward such as $1 for every point - Refund this purchase - The points are deducted again **Why the fix:** The points do not need to be refunded after a refund, but they don't have to be paid again. The total point for this refund order is now set to zero in case of a refund. This means the transaction will not be visible on the Coupon Card in the Loyalty Program. opw-4771724 Forward-Port-Of: odoo/odoo#217010 Forward-Port-Of: odoo/odoo#212922
The IoT Wi-Fi status check now avoids triggering slow network scans when loading homepage data. This prevents occasional 5-15 second delays and gives users a faster, more consistent homepage experience.
Original PR description
Before this commit, the `get_current()` method in the wifi helper would occasionally run very slowly, taking 5-15 seconds. This is because the `nmcli` command it was calling would periodically re-scan the network so the information it returned was up-to-date. Because the homepage data controller used this method, it would also sometimes take 5-15 seconds to load, leading to a bad experience for the user. After this commit, the `get_current()` method uses a different `nmcli` command that only shows the status of the currently connected network, avoiding a re-scan and therefore always running quickly. task-4922640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217682
A typo in the IoT driver update process caused a configuration update to fail, which could block git checkout during updates. This fix corrects the issue so the update process can complete normally.
Original PR description
Introduced in odoo/odoo#213177. A simple typo meant the `update_conf` method was being called with a set instead of a dict, leading to an error being thrown and preventing the git checkout. This commit fixes the typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215397 Forward-Port-Of: odoo/odoo#215230
This fixes an automated website donation test so it handles the payment confirmation redirect as a single step. The change helps prevent false test failures and keeps the donation payment flow validation stable.
Original PR description
In this commit, we fix the donation_snippet_use tour. At the end of the tour, when you click on submit donation, you are redirected to a page "Your payment has been processed." From this page, you are then redirected to a page with "Thank you". This intermediate redirection page can be a problem if there are several steps that concern it because we do not know when the redirection will be triggered (in the first or the second step?) Therefore, it is essential to have only one step for intermediate redirections. 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#217448 Forward-Port-Of: odoo/odoo#216558
This update fixes an error that occurred when using the website editor to toggle Suggested Accessories. It updates the affected website sales views to match the newer template structure, so editors can manage these options without interruptions.
Original PR description
Description of the issue/feature this PR addresses: This issue has happened because of the standard change in the module. Current behavior before PR: Traceback click on Suggested Accessories, the…
Description of the issue/feature this PR addresses: This issue has happened because of the standard change in the module. Current behavior before PR: Traceback click on Suggested Accessories, the toggle button through the website editor. in v18.2 the module [website_event_sale](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_event_sale/views/website_sale_templates.xml#L24) and [website_sale_loyalty](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale_loyalty/views/website_sale_templates.xml#L128) is inherit the cart_line and target the [node](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_sale/views/templates.xml#L2087) is available in the view. But in version 18.3 this node is move to other [template](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/views/templates.xml#L2341) that's why the node is not find. Desired behavior after PR is merged: After the change i target the new [template](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale/views/templates.xml#L2435) so the node is now find. Issued PR-190720 [OPW- 4864959](https://www.odoo.com/odoo/project/70/tasks/4864959?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215180
This fixes an issue in the website editor where the overlay used to adjust a background image could appear at the wrong size in some page sections. The change makes the editing controls display correctly, helping users position background images without broken overlays or misplaced tooltips.
Original PR description
Before this commit in some snippets background overlay wouldn't have proper height because of the parent elements' height. This commit overrides it with `!important`. To reproduce the issue: - open website and start editing - drop columns snippet, add background image to one of the columns, click on it - Click on the background position option to change it(the one with a crosshair icon) - the overlay isn't shown properly, which also breaks the tooltip position Commit follows [the html_builder refactoring]. Copy of https://github.com/odoo/odoo/pull/215377 [the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb Related to task-4367641
Users creating a time off allocation can now remove the validity period without immediately triggering a system error. The form will instead show the normal required-field warning when saved, making the process clearer and preventing an unnecessary crash.
Original PR description
An error occurs if the Validity Period is removed while creating a new allocation. Steps to reproduce: --- - Install the `hr_holidays` module - Time Off > My Time > My Allocation - Open New and remove the `Validity Period` Traceback: --- `AttributeError: 'bool' object has no attribute 'strftime'` This commit ensures that changing the date won't cause an error, but instead will display a warning upon saving the form, as it is a required field. sentry-6709097746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216015
Sale orders created from CRM no longer carry the CRM lead's default salesperson into related records during confirmation. This prevents quality checks from being assigned to the wrong user, improving accuracy for teams using sales, CRM, and quality workflows.
Original PR description
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 Forward-Port-Of: odoo/odoo#215499
This fix makes automated checks for live chat chatbot step ordering more reliable under heavy system load. It ensures the step text is fully saved before continuing, reducing false test failures without changing business functionality.
Original PR description
This commit fixes the `test_chatbot_steps_sequence_ui` and the `test_chatbot_steps_sequence_with_move_ui` tours. Those tours create chat bot steps to check their order. To do so, they edit the textarea and click on the save button. However, under high load, the button can be clicked before the textarea is updated. When this occurs, the validation fails and the step is not created. This commit fixes the issue by waiting for the textarea content to update before clicking on the save button. fixes runbot-228498 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
This update adjusts an internal performance test so it matches the current expected behavior in the Discuss test suite. It helps keep automated checks accurate and reduces false alarms for developers, with no direct impact on end users.
Original PR description
Changing the `channel _to_store_defaults` query count to the correct value. This increase is related to #216031.
When creating a refund, users will no longer see unrelated receipt or move types in the selector. This keeps the refund process clearer and helps prevent accidental selection of an incorrect document type.
Original PR description
Currently, when creating a refund, the move type selector shows all possible move_type out there. We obviously don't want that... Solution: show only the current move type for refunds. task-4926014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents translation-related errors that could occur when sharing referral links or working with loan records. It changes how translated text is prepared so the system can reliably access the information it needs, improving stability for affected workflows.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198 Forward-Port-Of: odoo/enterprise#88632
This fixes Planning so copied shifts calculate open shift hours correctly when an employee is on leave. It prevents lunch breaks from being counted as extra working time, improving schedule accuracy and avoiding overstated allocated hours.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#89502
Forward-Port-Of: odoo/enterprise#73478The intercompany rules settings label for creating invoices was renamed to make its purpose easier to understand. This reduces confusion for users configuring automated transactions between companies.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/4b57698670a7762bb206ccb24417d63c8edc1a46 change the ux of the intercompany rules, but the naming is confusing for users. task-4907810 Forward-Port-Of: odoo/enterprise#89368
This fixes a validation error when using Sendcloud batch shipping for deliveries split into packages with average weights that are not whole numbers. The system now sends weights in the integer format required by Sendcloud, allowing affected deliveries to be validated successfully.
Original PR description
### Steps to reproduce: - Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method. - Create a…
### Steps to reproduce:
- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
- set quantity to 1 -> put in pack
- set quantity to 2 -> put in pack
- set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation: weight: "A valid integer is required."
### Cause of the issue:
Sendcloud's api only accept integer values for the weight:
However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44
opw-4874063
Forward-Port-Of: odoo/enterprise#89495This fix ensures Odoo waits for the user to choose a printer before continuing with queued reception reports and labels. It prevents the printer selection window from closing too soon, so documents are correctly sent to the IoT-connected printer during inventory reception workflows.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Validate the Reception of the order -> Result: Odoo will prompt the customer to select a printer, however we are not able to choose a printer in time as the process continues without selecting one. This in return does not send the report to the printer via IoT. The root cause of this bug is that the IoT report handler JS function returns too early, it resolves once the printer selection popup has appeared, instead of resolving once the printer has actually been selected and is starting to print. Therefore the multi-report printing code assumes the print is done and triggers the next print, which causes the popup to close before the user can select a printer. To solve this bug, we listen for a 'printer-selected' event in the handler, and resolve only once we have received this event. This fixes the flow, allowing a printer to be selected for each report that is being printed in sequence. opw-4790299 Forward-Port-Of: odoo/enterprise#89617 Forward-Port-Of: odoo/enterprise#88538
Studio now closes the New Model dialog immediately after a user confirms it, instead of leaving it visible while waiting for the server. This removes a brief flicker and makes creating models feel smoother and more responsive.
Original PR description
This commit fixes a minor UX issue where the "New Model" dialog in Studio would remain visible briefly after confirmation, causing a flicker while waiting for the server response. The dialog now closes immediately upon confirmation, providing a smoother user experience. task-4809049 Forward-Port-Of: odoo/enterprise#88964
Installing Field Service with Sales no longer fails if the default Services product category was previously deleted. The setup now skips the missing category instead of stopping with an error, helping users complete installation without manual repair.
Original PR description
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently a ParseError is arising when the user installs the `industry_fsm_sale` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `industry_fsm_sale` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError
while parsing /home/odoo/src/enterprise/saas-18.3/industry_fsm_sale/data/industry_fsm_data.xml:5, somewhere inside <record id="field_service_product" model="product.product">
<field name="name">Field Service</field>
<field name="project_id" search="[('id', '=?', ref('industry_fsm.fsm_project', raise_if_not_found=False)), ('is_fsm', '=', True)]"/>
<field name="service_tracking">task_global_project</field>
<field name="type">service</field>
<field name="categ_id" ref="product.product_category_services"/>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6377659355
Forward-Port-Of: odoo/enterprise#89510UPS deliveries to customers in Mexico can now be processed successfully because each package includes the required merchandise description. This prevents shipment validation failures caused by missing package-level information in the UPS REST connector.
Original PR description
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a…
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a Merchandise Description.` **Expected behavior:** Can process shipment. **Steps to reproduce:** 1. Create a UPS rest delivery option 2. Create an SO for some product to a Mexico-based client, add the UPS delivery, confirm, try to validate the delivery -> 400 **Cause of the issue:** For non-return shipments, the description in the Package object is `None`, but when the receiver is based in Mexico, this field is required. **Fix:** Create a package level description based on the one added here: https://github.com/odoo/enterprise/commit/a7b8673364e0ac626bcc8ded72501c4f2866564c To the UPS API spec here: https://developer.ups.com/tag/Shipping?loc=en_PE&tag=Rating#operation/Shipment!path=ShipmentRequest/Shipment/Package/Description&t=request opw-4508139 Forward-Port-Of: odoo/enterprise#86411
Credit notes in the Kenya eTIMS integration can now only be submitted when the related invoice has already been successfully submitted. This helps prevent rejected or invalid tax submissions and keeps credit notes properly tied to compliant invoice records.
Original PR description
To ensure credit notes are only submitted for invoices that have been submitted to eTIMS, we now restrict credit note submission to cases where the related invoice has already been successfully submitted. Forward-Port-Of: odoo/enterprise#89464 Forward-Port-Of: odoo/enterprise#89385