Monday, November 3, 2025
15 changes · saas-18.4
Enhancements to existing features
The booking screen in the Point of Sale no longer automatically opens the keyboard on phones and tablets when it loads. This makes the screen easier to use on touch devices and avoids interrupting users with an unnecessary keyboard pop-up.
Original PR description
Task: [#5016943](https://www.odoo.com/odoo/project/1737/tasks/5016943) --- On tablets and phones, the search bar was autofocus when opening the booking screen in the POS frontend. This was causing the keyboard to open automatically, which was not a good user experience. Now the search bar is not autofocus on touch devices for the booking screen by creating a new controller to manage this. Forward-Port-Of: odoo/enterprise#96873
The POS configuration kanban view no longer automatically focuses the search bar on tablets and phones. This prevents the on-screen keyboard from opening unexpectedly, making the screen easier to use on touch devices.
Original PR description
Task: [#5016943](https://www.odoo.com/odoo/project/1737/tasks/5016943)
---
On tablets and phones, the search bar was autofocus when opening the POS config kanban view. This was causing the keyboard to open automatically, which was not a good user experience.
Now the search bar is not autofocus on touch devices for the POS config kanban view ('view_pos_config_kanban').
Forward-Port-Of: odoo/odoo#231045This change adds a set of shared helper methods for accounting tests, such as creating invoices, sale orders, reversals, and down payment invoices. It gives the accounting team a common starting point for test setup, making future testing work faster and more consistent across localizations.
Original PR description
This commit adds bunch of helper methods on AccountTestInvoicingCommon to make it easier to do generic accounting test actions, such as: - creating invoice - creating sale order - reversing invoice - skipping test if module isn't installed - creating down payment invoice ... and many more. We're aware that there are thousands of different helpers for creating invoice out there in different localizations. This commit serves as the first necessary step to create one standard that can be extended across all other test helpers. This is a simplified version of the merged commit in master. We are not refactoring/rewriting any other test to use these new helpers. Our goal is just to make it available for everyone to start using this helper on their accounting-related tests. task-4891206 Forward-Port-Of: odoo/odoo#233869 Forward-Port-Of: odoo/odoo#233724
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
Code cleanup and technical improvements
This change moves the preparation of product revaluation values into a separate internal method. It makes the process easier for custom extensions to plug into without changing the core behavior, improving flexibility for businesses with tailored stock/accounting workflows.
Original PR description
This allows to make it hookable by custom addons This was split from https://github.com/odoo/odoo/pull/160527 cc @pfertyk @sys-odoo @Whenrow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230265 Forward-Port-Of: odoo/odoo#228204
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