Odoo Changelog — 2025-06-17

Tuesday, June 17, 2025

3 changes · saas-18.2

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mail: prevent action buttons from showing in chatter on unsaved forms

Coresaas-18.2mail

This fix prevents message action buttons in the chatter from appearing on forms that have not yet been saved. It avoids a user-facing error when someone tries to mark a chatter message as to-do before the related record exists, improving form reliability.

Original PR description

Currently, an error occurs due to message action buttons being visible on unsaved forms. Steps to replicate: - Open any module with chatter (eg. `sale_management`). - Click on `Mark as todo` (star…

Currently, an error occurs due to message action buttons being visible on unsaved forms.

Steps to replicate:
- Open any module with chatter (eg. `sale_management`).
- Click on `Mark as todo` (star icon) without saving (hover near to user's name in chatter).

Error:
`TypeError: 'float' object is not iterable`

The error occurs due to a recent [commit](https://github.com/odoo/odoo/pull/211362/files#diff-0fc14194d473213159537bf41f421dcbaf940dfd81ac87d263b196e914d40af3R160) that added the d-flex class to the `<div>` [1] containing the message actions. The core issue lies in the use of `d-flex`, which overrides any conditional visibility logic [2] applied to its child elements. As a result, the message action buttons become visible even before the form is saved.

This commit resolves the issue by making the visibility logic important so it doesnt get overridden by `d-flex`. This ensures that the conditional visibility logic is respected, preventing the action buttons to appear before the form is saved.

[1] - https://github.com/odoo/odoo/blob/e7cbe74f388ed1177d4c5c6fbe54988a1dc18217/addons/mail/static/src/core/common/message.xml#L160

[2] - https://github.com/odoo/odoo/blob/e7cbe74f388ed1177d4c5c6fbe54988a1dc18217/addons/mail/static/src/chatter/web_portal/chatter.scss#L5-L7

https://github.com/user-attachments/assets/4a4d168d-961e-4b49-be84-c95b0d899b7b

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

#chatter#unsaved forms#message actions

[FIX] pos_discount: correctly load the Discount product

PR #214549

Coresaas-18.2pos_discount

This fix ensures the Point of Sale discount product is loaded in the correct way. It helps prevent issues during product loading that could affect discount handling in POS sessions.

Original PR description

Before this commit, the product.product record was loaded for the Discount product when loading the product templates, which caused several issues.

opw-4876402

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

#point-of-sale#discounts#product-loading

[FIX] mail: no rpc:mark_as_read assert twice

PR #214572

Coresaas-18.2mail

This update adjusts an internal Discuss test so it no longer fails unpredictably when a message is occasionally marked as read twice. The user impact is minimal: it acknowledges a rare duplicate background action while keeping automated checks reliable until a deeper design fix is decided.

Original PR description

Before this commit, a HOOT test in discuss was failing non-deterministically on runbot: ``` [HOOT] Test "@mail/thread/thread/mark channel as fetched when a new message is loaded and thread is…

The test should RPC mark as read once but rarely does twice instead. This happens because the condition for mark as read depends on whether the current user has seen the last message[1] and the RPC is not triggered again while marking as read is ongoing[2].

The problem is that "current user has seen" data are received from bus notification, while the "ongoing marking as read" window is until RPC response. This means it will properly make mark-as-read RPC once as long as the bus notification is received before the RPC response.

In rare case the bus notification is received after, then the code[1] will think the user hasn't read the last message and also there's no ongoing marking as read [2] therefore it will trigger a RPC again.

This problem shows a design issue with code flow using both RPC response and bus notifications. RPC response is simpler to understand but doesn't scale with Discuss needs, and since recently bus notifications did not work in tours so we were tempted to make discuss work a bit in tours thanks to RPC responses.

One idea to solve this problem would be to rely solely on bus notifications, so every flow that expects RPC return should actually await the related bus notification response. While we are deciding on this topic, this commit just relax the test to assert at least one "mark as read".

In practice a user may sometimes "mark as read" twice, but this is a known and minor issue for now until we find a better design to fix this problem once and for all.

[1]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L337
[2]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L357

runbot-223240

Currently, an error occurs due to message action buttons being visible on unsaved forms. Steps to replicate: - Open any module with chatter (eg. `sale_management`). - Click on `Mark as todo` (star icon) without saving (hover near to user's name in chatter). Error: `TypeError: 'float' object is not iterable` The error occurs due to a recent [commit](https://github.com/odoo/odoo/pull/211362/files#diff-0fc14194d473213159537bf41f421dcbaf940dfd81ac87d263b196e914d40af3R160) that added the d-flex class to the `<div>` [1] containing the message actions. The core issue lies in the use of `d-flex`, which overrides any conditional visibility logic [2] applied to its child elements. As a result, the message action buttons become visible even before the form is saved. This commit resolves the issue by making the visibility logic important so it doesnt get overridden by `d-flex`. This ensures that the conditional visibility logic is respected, preventing the action buttons to appear before the form is saved. [1] - https://github.com/odoo/odoo/blob/e7cbe74f388ed1177d4c5c6fbe54988a1dc18217/addons/mail/static/src/core/common/message.xml#L160 [2] - https://github.com/odoo/odoo/blob/e7cbe74f388ed1177d4c5c6fbe54988a1dc18217/addons/mail/static/src/chatter/web_portal/chatter.scss#L5-L7 https://github.com/user-attachments/assets/4a4d168d-961e-4b49-be84-c95b0d899b7b sentry-6657359767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, the product.product record was loaded for the Discount product when loading the product templates, which caused several issues. opw-4876402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, a HOOT test in discuss was failing non-deterministically on runbot: ``` [HOOT] Test "@mail/thread/thread/mark channel as fetched when a new message is loaded and thread is focused" failed: ``` The test should RPC mark as read once but rarely does twice instead. This happens because the condition for mark as read depends on whether the current user has seen the last message[1] and the RPC is not triggered again while marking as read is ongoing[2]. The problem is that "current user has seen" data are received from bus notification, while the "ongoing marking as read" window is until RPC response. This means it will properly make mark-as-read RPC once as long as the bus notification is received before the RPC response. In rare case the bus notification is received after, then the code[1] will think the user hasn't read the last message and also there's no ongoing marking as read [2] therefore it will trigger a RPC again. This problem shows a design issue with code flow using both RPC response and bus notifications. RPC response is simpler to understand but doesn't scale with Discuss needs, and since recently bus notifications did not work in tours so we were tempted to make discuss work a bit in tours thanks to RPC responses. One idea to solve this problem would be to rely solely on bus notifications, so every flow that expects RPC return should actually await the related bus notification response. While we are deciding on this topic, this commit just relax the test to assert at least one "mark as read". In practice a user may sometimes "mark as read" twice, but this is a known and minor issue for now until we find a better design to fix this problem once and for all. [1]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L337 [2]: https://github.com/odoo/odoo/blob/saas-18.2/addons/mail/static/src/discuss/core/common/thread_model_patch.js#L357 runbot-223240