Odoo Changelog — 2026-01-24

Saturday, January 24, 2026

3 changes

Refactoring(3)

Code cleanup and technical improvements

[REF] iot, pos_iot, pos_iot_adam_scale: move `manual_measurement` out of iot

Enterprisemasterpos_iot_adam_scaleiotpos_iot

This update streamlines the handling of manual measurements related to Adam scales by moving the `manual_measurement` field to a dedicated module, `pos_iot_adam_scale`. This improves organization and reduces complexity within the core IoT system.

Original PR description

As the `manual_measurement` field is only specific to adam scales, we moved it to the `pos_iot_adam_scale` module.

see odoo/upgrade#9210

#iot#scales#adam

[MERGE][MOV] website_sale(_* -> {}): merge wishlist & comparison into base module

PR #242898

Coremasterwebsite_saleMEDIUM

This update consolidates the wishlist and comparison features into the base website sale module, simplifying the codebase and improving maintainability. This change streamlines the eCommerce experience by removing redundant modules and optimizing data processing for product pages.

Original PR description

`website_sale_wishlist` & `website_sale_comparison` were holding the 'Wishlist' & 'Comparison' eCommerce features.

In the past, they were optional and installed through the eCommerce settings, since 19.0 they are auto-installed (features are enabled/disabled through the website editor).

For code simplification and maintainability, those two features are considered part of a standard eCommerce flow and are now moved into the base `website_sale` module.  This allows to remove multiple bridge modules too (and centralize some logic).

task-5089613

#eCommerce#wishlist#comparison#optimization

[REF] l10n_es_reports: improve BOE generation

PR #99404

Enterprisemasterl10n_es_reportsMEDIUM

This update simplifies the process of creating Spanish BOE reports for models 111, 115, and 303. By removing unnecessary encoding and streamlining the generation logic, we've made the process more efficient and easier to maintain, addressing previous issues with complexity and error-proneness.

Original PR description

In Spain, the BOE is a text file generated for each modelo (aka report). It is a .txt file in which the index of the character is the sole indicator of its content.

The generation of those text files is over-engineered,  contains way too much verbose, is error-prone and not change friendly, although the rules tend to change quite often.

First, added tests to ensure that the BOE are unaffected by the refactor. 

Then, simplified the BOE generation for modelos 111, 115 and 303:

* Removed the byte-encoding: the only purpose of this was to allow for an easy removal of accentuated characters. This however implied a byte-conversion in every single function. Normalised instead using the character's ascii position.
* Added helper functions for common operations (adding X blank spaces, formatting currency...)
* United all time-bound legal changes in the beginning of the boe's computation, so legal requirements are clear and isolated,
* Streamed the BOE generation in a single simple array.
* (+ other minor case-by-case improvement)

This is a proof of concept which is why other modelos are yet unaffected. They should be ASAP though ; when it is done, the more complicated functions should be removed.

task-5213590

#reports#Spain#BOE#tax

`website_sale_wishlist` & `website_sale_comparison` were holding the 'Wishlist' & 'Comparison' eCommerce features. In the past, they were optional and installed through the eCommerce settings, since 19.0 they are auto-installed (features are enabled/disabled through the website editor). For code simplification and maintainability, those two features are considered part of a standard eCommerce flow and are now moved into the base `website_sale` module. This allows to remove multiple bridge modules too (and centralize some logic). task-5089613

In Spain, the BOE is a text file generated for each modelo (aka report). It is a .txt file in which the index of the character is the sole indicator of its content. The generation of those text files is over-engineered, contains way too much verbose, is error-prone and not change friendly, although the rules tend to change quite often. First, added tests to ensure that the BOE are unaffected by the refactor. Then, simplified the BOE generation for modelos 111, 115 and 303: * Removed the byte-encoding: the only purpose of this was to allow for an easy removal of accentuated characters. This however implied a byte-conversion in every single function. Normalised instead using the character's ascii position. * Added helper functions for common operations (adding X blank spaces, formatting currency...) * United all time-bound legal changes in the beginning of the boe's computation, so legal requirements are clear and isolated, * Streamed the BOE generation in a single simple array. * (+ other minor case-by-case improvement) This is a proof of concept which is why other modelos are yet unaffected. They should be ASAP though ; when it is done, the more complicated functions should be removed. task-5213590