Monday, November 3, 2025
11 changes · saas-18.4
Resolved issues and error corrections
Dimona-related employee fields are now displayed only for Belgian employees instead of appearing for everyone. This reduces confusion for companies operating outside Belgium and keeps employee contract screens more relevant.
Original PR description
Before this commit, the fields about dimona were shown for all employees, now these fields will be displayed only for belgian employees. task-5148931 Forward-Port-Of: odoo/enterprise#98484 Forward-Port-Of: odoo/enterprise#96496
The Cambodian accounting package now uses unique tax names to prevent installation errors when setting up the chart of accounts manually. This helps businesses using Cambodian localization complete accounting configuration reliably.
Original PR description
Fixes an issue where some taxes in the Cambodian package have the same name, leading to errors when manually installing the chart template. Interestingly enough, the constraints does not trigger on the demo data company. Task [link](https://www.odoo.com/odoo/project.task/5194444) task-5194444 Forward-Port-Of: odoo/odoo#233066 Forward-Port-Of: odoo/odoo#232968
**Steps to reproduce:** 1. Install the `website_sale` module. 2. Create a product with multiple variants. 3. Archive one of the variants. 4. Publish the product on the website. 5. Try selecting the archived variant. **Observed behavior:** * The variant appeared greyed out without any alert, leaving users without feedback. **Root cause:** * The alert element was removed in this [commit](https://github.com/odoo/odoo/commit/eac892a4ad7373d18f954afbbcd2f1213ac5f281). **Solution:** *
Original PR description
**Steps to reproduce:** 1. Install the `website_sale` module. 2. Create a product with multiple variants. 3. Archive one of the variants. 4. Publish the product on the website. 5. Try selecting the archived variant. **Observed behavior:** * The variant appeared greyed out without any alert, leaving users without feedback. **Root cause:** * The alert element was removed in this [commit](https://github.com/odoo/odoo/commit/eac892a4ad7373d18f954afbbcd2f1213ac5f281). **Solution:** * Restore the alert in the template and toggle its visibility in the JS handler. * Selecting an archived variant now displays the message: “This combination does not exist”. opw-5069059
[FIX] website: get scroll from document element for footer animation __Current behavior before commit:__ Since [this PR], the scrolling is not done on `#wrapwrap` anymore. Now when an animation is set on an element inside the footer it will not appear if a slideout effect is set on it. __Description of the fix:__ Get `scrollTop` and `scrollHeight` from the document element instead of `#wrapwrap` and add a test tour. __Steps to reproduce:__ 1. Open the Website builder. 2. Click on
Original PR description
[FIX] website: get scroll from document element for footer animation __Current behavior before commit:__ Since [this PR], the scrolling is not done on `#wrapwrap` anymore. Now when an animation is…
[FIX] website: get scroll from document element for footer animation __Current behavior before commit:__ Since [this PR], the scrolling is not done on `#wrapwrap` anymore. Now when an animation is set on an element inside the footer it will not appear if a slideout effect is set on it. __Description of the fix:__ Get `scrollTop` and `scrollHeight` from the document element instead of `#wrapwrap` and add a test tour. __Steps to reproduce:__ 1. Open the Website builder. 2. Click on a column in the footer. 3. Set an "On Appearance" Animation on it. 4. Set the footer Slideout Effect to "Slide Hover". 5. Add some content on the page so that it's needed to scroll for the footer to be visible. 6. Save. 7. Scroll to the footer. => The column doesn't appear. [this PR]: https://github.com/odoo/odoo/pull/98429 --- [FIX] website: scroll on new entry in faq horizontal __Current behavior before commit:__ Since [this PR][1], the scrolling is not done on `#wrapwrap` anymore. Now when adding a new entry to the snippet faq horizontal, the page doesn't scroll automatically to the new entry. This behavior has actually never worked because [the PR that introduced faq horizontal][2] was merged just after [the PR that moved the scrolling to the document element][1]. __Description of the fix:__ Get `scrollTop` and `scrollHeight` from the document element instead of `#wrapwrap` and add a test tour. __Steps to reproduce:__ 1. Open the Website builder. 2. Drag a Text block 3. Choose the FAQ horizontal snippet 4. Click on "Add New" => The page doesn't scroll to the new entry. [1]: https://github.com/odoo/odoo/pull/98429 [2]: https://github.com/odoo/odoo/pull/176438 Forward-Port-Of: odoo/odoo#233911 Forward-Port-Of: odoo/odoo#228396
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors. ### Steps to reproduce: - In the settings enable "Batch Transfers" - Inventory/Operations/Transfers/Batch Transfers - Create a new batch and do not confirm it - Go to the barcode app > Batch Transfers > Clear filters - Select your draft batch
Original PR description
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which…
### Issue: Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors. ### Steps to reproduce: - In the settings enable "Batch Transfers" - Inventory/Operations/Transfers/Batch Transfers - Create a new batch and do not confirm it - Go to the barcode app > Batch Transfers > Clear filters - Select your draft batch - Scan anything #### > Traceback #### Other issues: The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done". ### Cause of the issue: Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179 opw-5162164 Forward-Port-Of: odoo/enterprise#98022 Forward-Port-Of: odoo/enterprise#97526
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233925 Forward-Port-Of: odoo/odoo#231397
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233925 Forward-Port-Of: odoo/odoo#231397
This update fixes an unreliable automated test in the web editor so it no longer fails intermittently when the system is under load. It helps ensure smoother quality checks and reduces false alarms during testing, without changing the product’s visible behavior.
Original PR description
This test was not awaiting each step properly, which becomes visible when the runbot is overloaded and the querySelector calls return null, at which point accessing `click` or `value` would trigger a traceback. runbot-161423 Forward-Port-Of: odoo/odoo#233900
This update prevents text from being highlighted twice when an existing highlight is already present on a parent element. It makes editing more consistent and avoids visual duplication that could confuse users.
Original PR description
Problem: When a text highlight is applied on a node that has an ancestor with the same text highlighted, both highlights remain. The ancestor's highlight should be removed before applying the new one. Cause: When applying highlight, it is done on the text node (leaf node). However, one of the ancestors might already have the highlight applied. This is not removed, leading to duplicate highlights. Solution: When applying the highlight, check if an ancestor has the same text and highlight style applied. If so, remove it before applying the new highlight. Steps to reproduce: 1. Add text "ABC". 2. Apply text highlight on "B". 3. Apply animation on "B". 4. Apply text highlight on "ABC". 5. In the DOM, "B" has two highlights (visually noticeable). opw-5014674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a small issue in the Belgium POS black box module when receiving orders from Urban Piper. It helps ensure these orders are handled correctly and reduces the chance of order-processing problems at the point of sale.
Original PR description
Fix small issue in `pos_blackbox_be` module when accepting orders from Urban Piper. Forward-Port-Of: odoo/enterprise#98563
This change corrects a test setup issue in the HTML builder so it uses the proper base option component. It helps keep the automated tests aligned with the current implementation, reducing the risk of false failures and ensuring more reliable validation of future changes.
Original PR description
In PR https://github.com/odoo/odoo/pull/220746, we forgot to replace the use of Component with BaseOptionComponent in few tests. This commit fixes that. 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
Website menus linked to pages will now only appear active when the current URL matches exactly. This prevents similar page titles from being highlighted at the same time, making navigation clearer for visitors.
Original PR description
__Current behavior before commit:__ A menu is shown as active if the unslug version of its URL matches the current accessed URL. The issue is that the unslug version of a menu linked to a page has no real meaning. Such menu should only be shown as active if the request URL path matches exactly. __Description of the fix:__ Added a check to ensure that when a menu is linked to a page, it isn't shown as active if its path doesn't exactly match the request path. __Steps to reproduce:__ 1. On the website, go to Site > Pages 2. Create a new page with title "iOS 26" and another page with title "iPadOS 26" 3. Go to /ios-26 4. Both menus "iOS 26" and "iPadOS 26" are highlighted task-5094899 Forward-Port-Of: odoo/odoo#233865 Forward-Port-Of: odoo/odoo#230623