Odoo Changelog — 2025-05-29

Thursday, May 29, 2025

2 changes · 18.0

Bug Fixes(2)

Resolved issues and error corrections

[FIX] mrp: use the product's UoM precision for product_qty in unbuild

PR #211944

Core18.0mrp

Manufacturing unbuild forms now allow quantities with the same decimal precision as the product's unit of measure. This prevents valid manufactured quantities, such as three-decimal amounts, from being rounded or blocked when reversing a production order.

Original PR description

Steps to reproduce the bug:
- Set the decimal precision and rounding accuracy for the unit of measure to more than 2 digits (e.g. 3)
- Create a storable product “P1”
- Create a manufacturing order to produce 1.234 units
    - Confirm and validate it
- Try to unbuild the MO

Problem:
The unbuild form does not respect the product's UoM decimal precision, allowing only 2 digits for product_qty.

opw-4818591

#manufacturing#unbuild#unit of measure#quantity precision

[FIX] mail: keep showing 'is typing...' for long typers

PR #211961

Core18.0mail

This fixes an issue in Discuss where someone writing a long message could disappear from the "is typing..." indicator before they stopped typing. The indicator now refreshes correctly, giving other users a more accurate view of ongoing conversations.

Original PR description

Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds.

As a reminder, the "is typing..." feature in discuss is implemented as follow:
- when typing, notify `is_typing: true` once every 50 seconds.
- when stop typing for 5 seconds, notify `is_typing: false`.
- other members assume stop typing if nothing received after 60 seconds.

This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow

```
- time: 0sec. -> is_typing: true sent + received
- time: 50sec. -> is_typing: true sent + received
- time: 60sec. -> is_typing: false (assuming stop typing)
- time: 100sec. -> is_typing: true sent + received
```

This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing.

This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime.

runbot-223760

Steps to reproduce the bug: - Set the decimal precision and rounding accuracy for the unit of measure to more than 2 digits (e.g. 3) - Create a storable product “P1” - Create a manufacturing order to produce 1.234 units - Confirm and validate it - Try to unbuild the MO Problem: The unbuild form does not respect the product's UoM decimal precision, allowing only 2 digits for product_qty. opw-4818591

Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is implemented as follow: - when typing, notify `is_typing: true` once every 50 seconds. - when stop typing for 5 seconds, notify `is_typing: false`. - other members assume stop typing if nothing received after 60 seconds. This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow ``` - time: 0sec. -> is_typing: true sent + received - time: 50sec. -> is_typing: true sent + received - time: 60sec. -> is_typing: false (assuming stop typing) - time: 100sec. -> is_typing: true sent + received ``` This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing. This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime. runbot-223760