Odoo Changelog — 2025-02-25

Tuesday, February 25, 2025

65 changes · saas-18.1

Improvements(1)

Enhancements to existing features

[IMP] point_of_sale: serial-lot number dialog title

PR #197018

Coresaas-18.1point_of_sale

The Point of Sale interface now shows a clearer dialog title when selecting serial or lot numbers, with the product name separated for easier understanding. Printed receipts also display product attribute names at a more readable size, improving clarity for staff and customers.

Original PR description

In this commit:
----
- Improved the dialog title for better clarity.
- Product name separated in title.
- Adjusted attribute line size for better readability in print.

task-4551282,4570086


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#point of sale#receipts#serial numbers#lot numbers

Bug Fixes(9)

Resolved issues and error corrections

[FIX] iap: handle errors while calling JSON-RPC endpoint

PR #195762

Coresaas-18.1iap

This fix changes how certain IAP JSON-RPC endpoint errors are reported, replacing noisy error stack traces with clearer warnings. This reduces unnecessary log noise while still keeping administrators informed when validation or transaction-related issues occur.

Original PR description

Currently, an error occurs in the log when a ValidationError or InFailedSqlTransaction error occurs when calling the JSON-RPC endpoint in IAP.

error: `ConnectionError: null`

This is because [1] added logger.exception that logs every error in the log when it appears.

This commit will use the logger warning to print a warning in the terminal instead of the exception when a ValidationError or InFailedSqlTransaction error occurs.

[1] - https://github.com/odoo/odoo/commit/a1477d1d00adb928b149f8e019f65c00f75ef129

sentry-6059323528

#iap#logging#json-rpc

Other(55)

Miscellaneous changes

[FW][FIX] account: fix empty string and False/None inconsistencies

PR #199289

Coresaas-18.1accounthr_expense

Original PR description

**[FIX] account: fix empty string and False/None inconsistencies**

When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations.

This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior.

opw-4167139

[Enterprise PR](https://github.com/odoo/enterprise/pull/73256)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#191026
Forward-Port-Of: odoo/odoo#186079

In this commit: ---- - Improved the dialog title for better clarity. - Product name separated in title. - Adjusted attribute line size for better readability in print. task-4551282,4570086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently, an error occurs in the log when a ValidationError or InFailedSqlTransaction error occurs when calling the JSON-RPC endpoint in IAP. error: `ConnectionError: null` This is because [1] added logger.exception that logs every error in the log when it appears. This commit will use the logger warning to print a warning in the terminal instead of the exception when a ValidationError or InFailedSqlTransaction error occurs. [1] - https://github.com/odoo/odoo/commit/a1477d1d00adb928b149f8e019f65c00f75ef129 sentry-6059323528

**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. opw-4167139 [Enterprise PR](https://github.com/odoo/enterprise/pull/73256) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191026 Forward-Port-Of: odoo/odoo#186079

**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1. 2. Create a Manufacturing Order (MO) from this BoM. 3. Confirm the MO and set it to In Progress. 4. In the MO interface: Change the by-product from Product A to Product B. 5. Complete the MO. https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d **Current Behavior** The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A. **Expected Behavior** The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components). It would be worth to add the same kind of readonly condition on the byproduct side as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198522 Forward-Port-Of: odoo/odoo#194972

### Issue: When changing the location/dest of a picking, the location/dest of the stock moves are not updated and the user may not even notice it. ### To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Internal, New - Add an operation - Change the location and destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move #### Error: the location and destination location of the stock move are still the initial ones. ### Cause of the issue: The onchange method `_onchange_locations` of the "stock.picking" model: https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/stock/models/stock_picking.py#L825-L836 has been removed in saas-17.2 byt the push pull refactror: 11e69870db1c49d9a6af79ffd263e4e162b34b6b However, it should not have been for the "location_id" since it was not replaced by any other mechanic and it has been replaced by a compute method for the "location_dest_id": https://github.com/odoo/odoo/blob/5a61e440232b119f712ff9545ec3e535210bbb94/addons/stock/models/stock_move.py#L200-L201 However, this compute method is not triggered in the above flow for the following reason: On the picking model, there are two fields that contain the stock moves: https://github.com/odoo/odoo/blob/17a63a6cda41a44e3d4ff8b5a9042e93ba956bc8/addons/stock/models/stock_picking.py#L612-L614 Where `move_ids_without_packages` is a subset of `move_ids` When editing the operations of a picking, we are actually dealing with the field `move_ids_without_packages`. So, when changing the locations of the picking, the webclient sends the SMs via the field `move_ids_without_packages`, i.e.: the web client does not provide any value for `move_ids`. Server side, when creating a `new` record based on the provided values, we will handle the inverse of `move_ids_without_packages`, i.e.: we will make sure that the stock moves have the field `picking_id` correctly defined: https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L6366-L6374 **But** we don't define any value for the siblings of the field. It means that we don't set any value for the field `move_ids`. This will lead to the bug: later on in the onchange, we flag all fields that will have to be recomputed: https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L983 And here we would hope that the field `location_dest_id` of the stock moves will be flagged, as mentioned in the dependencies: https://github.com/odoo/odoo/blob/68ae97bd27fbdc874922e03f52f8b0c7953df801/addons/stock/models/stock_move.py#L206-L207 But... In `_modified_triggers`, at some point, we are here https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L7200-L7203 Where `field` is `stock.move.picking_id`. So, we iterate on the inverse field of `field`, i.e.: `move_ids` and `move_ids_without_packages`. However, as explicitly mentioned in the comment, we "use an inverse of field without domain", i.e.: `move_ids`. We therefore read the value of this field on the picking which is, because of the bug explained in the previous paragraph, an empty record. As a result, the ORM considers that it does not have to recompute any `location_dest_id`. The ORM team is aware of the issue. They have tried to write a generic solution (cf PR [191318](https://github.com/odoo/odoo/pull/191318)) but it led to a lot of other errors. So, the issue has been considered as a limitation and added to a todo list on their side. In the meantime, it is possible to patch the issue with a stock-specific fix. Note: the issue will also happen when editing an existing picking. Suppose a picking with one move SM01. The user adds a second move SM02, does not save and edits the destination location of the picking: for the same reasons, the ORM will only see SM01 and, therefore, will call the compute method for SM01 only. Contains a backport of 22e17e513e9d0309a832e27ee10f89a96688d905 Co-authored-by: "Adrien Widart (awt)" <awt@odoo.com> opw-4491101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198617 Forward-Port-Of: odoo/odoo#198504

Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an email message, has the MIME type `message/rfc822`. According to [RFC 2046 Section 5.2.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.2.1:~:text=No%20encoding%20other%20than%20%227bit%22%2C%20%228bit%22%2C%20or%20%22binary%22%20is%20permitted%20for%0A%20%20%20the%20body%20of%20a%20%22message/rfc822%22%20entity.), attachments of this MIME type must be encoded using `7bit`, `8bit`, or `binary`. However, the system currently encodes all attachments using Base64 by default, which is not compliant with the standard for `message/rfc822`. Although some email clients tolerate Base64 encoding for `message/rfc822`, others, such as Thunderbird, Roundcube, and Zimbra, strictly follow the RFC and reject Base64-encoded `message/rfc822` attachments. As a result, these attachments appear invalid and are downloaded as empty files. opw-4126522 Forward-Port-Of: odoo/odoo#198862 Forward-Port-Of: odoo/odoo#194988

Have an x2many list (non editable) or kanban, such that editing a record of the relation is done through the form view dialog. Have a default_order on the x2many view containing at least a field that isn't in the view. Before this commit, there were two issues occurring when the user clicked on "Save" (in the dialog footer) after editing a record in the dialog. 1) if the first field of the order wasn't in the view, e.g. `default_order="x"` but x wasn't in the view: there was a crash, because we tried to sort records on a field that is unknown. 2) if it wasn't the first field of the order, e.g. `default_order="x,y"` but y wasn't in the view: the changes done in the dialog were lost, so it was no possible to edit records. Both issues had the same root cause. After the edition, we tried to sort the relation (as the order might have changed). We do that since [1], but it wasn't the main purpose of this commit. It has been done because it looked like a quick win at the time, and we thought it was a good idea. However, functionally speaking, sorting the records after the edition isn't wanted. If I just clicked on a record, edited it, I expect the record to remain where it was after closing the dialog. So as sorting isn't necessarily wanted, and it even produces issues in some cases, this commit reverts that "feature". [1] https://github.com/odoo/odoo/commit/17e198153ecfd9c5c32b3b22f43e2f1b8100a1c3 Closes #197867 opw-4499150 (case (2)) 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#199070 Forward-Port-Of: odoo/odoo#198757

Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl is modifying the visibility of the field "Document number" to appear when necessary directly on latam_invoice_document view. This make that the field visibility is being changed on other localizations as well when you have both installed. Current behavior before PR: The "Document Number" field below "Document Type" should is present on uruguayan electronic invoices (where it should not be). Desired behavior after PR is merged: The "Document Number" field is present on chilean invoices as expected and not in uruguayan electronic invoices. Steps to reproduce the error: - Install l10n_uy - On the UY company, go to Customer/Invoices section, create one, select a customer and check that you have an electronic journal selected. The field "Document Number" should not be present. - Install l10n_cl - Go to the previously created invoice and check that the field "Document Number" now appears. Ticket ADHOC side: 86491 Ticket Odoo side: 4505977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195902

This traceback arises when the user tries to change the orders from one stage to another. after deleting the last stage in another tab. To reproduce this issue:- 1) Install `pos_restaurant` 2) Duplicate the tab and open the preparation display in one tab 3) In another tab delete the last stage(`complete`) for the above preparation display 4) In the first tab click any product of an order from the `ready` stage 5) Now click the `ready` icon of that order 5) At the terminal you will see a traceback Error:- ``` IndexError: list index out of range File "odoo/http.py", line 2252, in __call__ response = request._serve_db() File "odoo/http.py", line 1828, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo/http.py", line 1848, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 134, in retrying result = func() File "odoo/http.py", line 1826, in _serve_ir_http return self._serve_ir_http(rule, args) File "odoo/http.py", line 1833, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2058, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 740, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 38, in call_kw return self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 34, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 458, in call_kw result = getattr(recs, name)(*args, **kwargs) File "home/odoo/src/enterprise/saas-17.1/pos_preparation_display/models/preparation_display_orderline.py", line 51, in send_stricked_line_to_next_stage next_stage_id = stage_ids.ids[current_stage_index + 1] ``` When the user clicks on the current stage icon it is supposed to go to the next stage with the help of the current stage index + 1. But, because the user deleted the next stage it leads to an index error After applying this will resolve the issue by preventing the user to modify stages when there is an active session for that preparation display. Which making the code more robust sentry-5056416790 Forward-Port-Of: odoo/enterprise#59415

Improvements(1)

[IMP] point_of_sale: serial-lot number dialog title

Bug Fixes(9)

[FIX] iap: handle errors while calling JSON-RPC endpoint

Other(55)

[FW][FIX] account: fix empty string and False/None inconsistencies

Improvements(1)

[IMP] point_of_sale: serial-lot number dialog title

Bug Fixes(9)

[FIX] iap: handle errors while calling JSON-RPC endpoint

Other(55)

[FW][FIX] account: fix empty string and False/None inconsistencies

[FIX] mail: chat window above from view scrollbar

[FIX] point_of_sale: click on register after del

[FIX] point_of_sale: register translation issues

[FIX] account_followup: fix style on followup partner view

[FIX] mail: command palette mentioned and recent chat no duplicate

[FIX] l10n_in_reports_gstr: remove wrong call to super()

[FIX] pos_barcodelookup: replace call to a renamed action

[FIX] account_followup: fix style on followup partner view

[FW] 18.0 fix mult tours5 pipu

[FW][FIX] stock_picking_batch: fix error in test_group_by_country_and_produc

[FW][FIX] base: fix and add provinces for Indonesia

[FW][FIX] hr_homeworking: fixes to work location display on calendar

[FW][FIX] mrp: inconsistency between stock.move and stock.move.line when changing byproduct's product in MO

[FW][IMP] pos_loyalty: highlight action button when reward is available

[FW][FIX] website_sale: add disclaimer for combo product VAT included

[FW][FIX] account_edi: Skip documents in error

[FW][FIX] hw_posbox_homepage: clear Wi-Fi configuration

[FW][FIX] stock: sync SM loc with picking's loc

[FW][FIX] web: missing props in user_menu_items

[FW][FIX] stock_delivery: display shipping weight if picking is not done

[FW][FIX] mail: non deterministic public page tour

[FW][FIX] spreadsheet: fix inconsistent day of week

[FW][FIX] web: Fix search_bar holding arrowright triggers too many name_search

[FW][FIX] sale_project_stock: make a stock user can validate stock picking

[FW][FIX] point_of_sale: not include reference_code in exactMatch

[FW][FIX] mail: fix cross tab test debug mode

[FW][FIX] html_editor: banner selection issue

[FW][FIX] base: binary encode "message/rfc822" mail attachments

[FW][FIX] website_sale: hide Contact Us button if sale is possible

[FW][FIX] web: x2many: do not reload records after edition

[FW][FIX] web_editor: fix recognition of SVG mimetype

[FW][FIX] account: subtotals in tax totals as a sum

[FW][FIX] web: emoji picker search with 1 char

[FW][FIX] html_editor: prevent crash when deleting embedded state property

[FW][FIX] auth_totp: fix non-deterministic JS error

[FW][FIX] payment_paypal: fix payment from PoS

[FW][IMP] account: rename duplicated payment term

[FW][FIX] website_sale: fix parsing issue in "add to cart" snippet

[FW][FIX] html_editor: trailing br at the end of link

[FW][FIX] pos_restaurant: use custom selector for printed receipt header

[FW][FIX] pos_restaurant: show correct time in receipt

[FW][IMP] point_of_sale: split click on pricelist button

[FW][FIX] web: handle sign buttons disability with loaded draw signatures

[FW][FIX] mail: better message notification icon style

[FW][FIX] l10n_cl: document_type field visibility on localizations different than CL

[FW][FIX] l10n_mx_reports: filter account lines correctly

[FW][FIX] account: fix empty string and False/None inconsistencies

[FW][FIX] account_followup: fix extra spaces in chatter and pdf

[FW][ADD] l10n_uy_edi: Global Discount Support + Down Payment

[FW][FIX] account_batch_payment: create a batch with branch payments

[FW][FIX] hr_payroll_expense: refund in payslip action accessible to payroll manager

[FW][FIX] l10n_mx_edi_extended: Tax ID number in external trade

[FW][IMP] l10n_ec_edi: Add flow tests

[FW][FIX] spreadsheet: fix inconsistent day of week

[FW][FIX] l10n_cz_reports_2025: manifest was preventing to auto install

[FW][FIX] appointment: fix missing dependency in website

[FW][FIX] documents: allow loading records with res_field in attachments

[FW][FIX] spreadsheet_dashboard_account_accountant: minor fixes

[FW][FIX] pos_preparation_display: fix tracebackback when stages deleted in backend

[FW][FIX] sign: sign_all button disabled conditions fix

[FW][FIX] l10n_pl_reports_jpk: remove partial namespace from jpk

[FW][FIX] project_account_budget: fix the issue of budget views