Saturday, April 25, 2026
4 changes · master
Resolved issues and error corrections
This update streamlines the process of marking projects as 'Unreachable' within Odoo. Instead of a dynamic creation method, a pre-defined XML record is now used, leading to more reliable and efficient synchronization. The change removes an older, less efficient method and updates associated tests.
Original PR description
Replace dynamic creation of the "Unreachable" tag with a static XML record `project_tag_db_unreachable` and use `env.ref()`. Remove the old helper method `_get_unreachable_tag_id()` and update tests accordingly. Forward-Port-Of: odoo/enterprise#115009
This update resolves an issue where users were repeatedly prompted with a zero-demand warning when validating immediate receipts created using the barcode module. The change bypasses this warning for immediate transfers, streamlining the process and preventing unnecessary interruptions. This ensures accurate receipt validation without manual intervention.
Original PR description
Issue before this commit: ========================= When validating an immediate receipt, the user gets a zero-demand warning wizard, even though quantities are actually being received. Steps to…
Issue before this commit: ========================= When validating an immediate receipt, the user gets a zero-demand warning wizard, even though quantities are actually being received. Steps to Reproduce: ========================= - Install the stock_barcode module - Create an immediate receipt. - Validate it. - The zero-demand warning wizard appears. Cause of the issue: ========================= This behaviour was introduced in a [PR](https://github.com/odoo/odoo/pull/241646/changes/0238ff2cdd58524da1d7fccb411a94d2bce73094) to warn users when confirming/validating a picking with zero-demand moves. However, for immediate transfers, demand (product_uom_qty) is always 0, so the condition is always true and the wizard is always shown, even when quantities are being processed. With This Commit: ========================= Avoid showing the zero-demand warning wizard when validating an immediate picking from the barcode interface. Forward-Port-Of: odoo/enterprise#114867
This update resolves an issue where barcode quantities were displayed with slight rounding errors due to how JavaScript handles decimal numbers. The fix ensures accurate quantity representation, particularly when dealing with batch transfers and wave operations, improving data reliability.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to Settings and enable: * Storage Locations (Warehouse). * Batch, Wave & Cluster Transfers. * Create a Product and set its on-hand quantity to…
**Steps to reproduce:**
* Install `stock` module.
* Go to Settings and enable:
* Storage Locations (Warehouse).
* Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
* Set Type of Operation to Internal Transfer.
* In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
* Select the newly created Operation Type.
* Add the created Product with quantity 4.4.
* Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
* Select the same Operation Type.
* Add the same Product with quantity 48.8.
* Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
* Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.
**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).
**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:
https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205
- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.
**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats
- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.
---
opw-5932329
Forward-Port-Of: odoo/enterprise#114998
Forward-Port-Of: odoo/enterprise#110241Code cleanup and technical improvements
This update cleans up test code by removing redundant use of the 'tracking_disable' context key. This simplifies test readability and reduces potential performance issues, ensuring tests are more reliable and focused on core functionality. It's a housekeeping task improving test quality and maintainability.
Original PR description
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in…
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in mind when asked to authors or when reading commit messages. Partly because people tend to copy-paste code patterns without really understanding the purpose of those. See individual commits for more details. USAGE IN TESTS Lots of tests use the 'tracking_disable' or 'mail_notrack' context keys. However I bet most of those are there just because they were copy pasted, and without any thinking about the usage * it is used on non-thread models (which shows writer did not check what it was about); * it is copy-pasted in multiple unit tests creating one data each time (which shows performance are not the matter here as the writer could use a setupClass); * most usage is done when creating records, although there is no tracking at create time. And even if someday tracking at create comes back it would not be a performance issue on a test db compared to current test workload (too much tests, tours that are slow, ...). It also deactivates creation message log and initial follower (if not root) but those insert should be fast; * mail.thread is part of the real life stack and should be tested in functional addons. It notably has an impact on followers which means ACLs, partner_id field setup, field computation and invalidation, cache usage, ... Better remove most of them, and keep only relevant one (e.g. batch creation, simulating environment like Payroll, ...). Task-6094598 Followup of Task-3645865 Forward-Port-Of: odoo/enterprise#113258