Odoo Changelog — 2024-07-29

Monday, July 29, 2024

3 changes · 17.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] account_audit_trail: allow merging partners

Core17.0account_audit_trail

Businesses can now merge duplicate partner records even when audit trail tracking is active. The change keeps audit protections in place while allowing this controlled cleanup because no information is lost.

Original PR description

When the audit trail feature was enabled, it was impossible to merge the partners.
Since we don't lose any information, we allow that action specifically.

Because it should never be allowed in non controlled settings, we use a python token so that the context key cannot be used with RPC calls.

#audit trail#partners#merge#data cleanup

[FIX] hw_drivers: remove useless log warnings

PR #174702

Core17.0hw_drivers

Hardware driver messages that occur during normal disconnected states are now logged as informational instead of warnings. This keeps useful details available while reducing noise in warning logs, making real issues easier to spot.

Original PR description

Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior

1) When no database is connected we log "warning invalid ssl
   certificate"
2) When no database is connected we log "warning odoo server not set"

I log both as info level to still keep this information but avoid spamming useful error logs with it

#logging#hardware#noise reduction

[TEST] double onchange lot_ids

PR #168331

Core17.0stock

Adds test coverage for a stock delivery issue where removing multiple serial numbers could accidentally clear the remaining assigned serial number. This helps ensure warehouse staff can safely adjust serial-tracked deliveries without losing the correct quantity or traceability information.

Original PR description

Here is a little test to check the onchange for multiple unlinks ### Steps to reproduce: - Create a storable product SP tracked by serial number - Register 3 serial numbers SN01, SN02 and SN03 in…

Here is a little test to check the onchange for multiple unlinks

### Steps to reproduce:

- Create a storable product SP tracked by serial number
- Register 3 serial numbers SN01, SN02 and SN03 in stocks for that product (this can for instance be achieved by creating and validating a receipt where you assigned the serial numbers)
- Create a delivery order for these 3 units and mark as to do
- "Extend" the stock move of the picking to see the serial numbers, remove two of them of then and save

### Expected behavior:

The last serial number remains assigned to the stock move

### Current behavior:

The quantity set on the stock move is zero and hence saving the record will remove all associated stock move line and hence every remaining SN

Cause of the issue:

The "lot_ids" field of the stock.move model is a computed non-stored many2many field.

The first time we remove an SN, an onchange setting the "lot_ids" of the stock move is performed and correctly updates the new record both in terms of quantity and lots/stock.move.line.
On the other hand, the second time that we remove a serial number, the onchange tries to modify two times the SN linked to our move. Once by modifying the "lot_ids" of the "move_ids_without_package" of the picking with an "update" command and once more by modifying the dirrectly the "lot_ids" of stock move with two unlink (the previous one and the current one). However, the first of these update will incorrectly set the "lot_ids" to an empty value in the cache since, to not modify the "move_ids_without_package" directly on "real" record, a "new" picking will be created to update the cache:
https://github.com/odoo/odoo/blob/b11480e757ba35e0c616b84bf4dd801210de66f0/addons/web/models/models.py#L1030
However, during this call of the "new" method, the cache is updated again:
https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/models.py#L6436-L6437
but this time with the validate parameter equal to false ! During this call, the lot_ids of the the stock move of the "new"picking
will be updated using the ids provided by the "convert_to_cache" method here:
https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/models.py#L6003-L6004
However, the convert_to_cache method of multirelational field, clears all the ids of an unlink operation in case validate is set to false because of these lines:
https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/fields.py#L4207
https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/fields.py#L4220-L4221
As a result, the lot_ids of the stock_move is set to be empty in cache. Soon after the "_onchange_lot_ids" method is triggered to compute the quantity linked of products related to the stock.move:
https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/addons/stock/models/stock_move.py#L1121-L1123
Since the lot_ids is set to an empty record set in cache, this value is used and a quantity of 0 is set. As such, the stock move line linked to the move will be unlinked to the move when a save is performed.

### Note:

This flow use to work correctly as, before 17.0, the command set was used instead of unlink to perform the changes on the lot_ids. This has been changed by the following commit: https://github.com/odoo/odoo/commit/e4b66668e0ff3d5444ef7fc7b79e6226c513e2c0

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

When the audit trail feature was enabled, it was impossible to merge the partners. Since we don't lose any information, we allow that action specifically. Because it should never be allowed in non controlled settings, we use a python token so that the context key cannot be used with RPC calls.

Currently the logs are being spammed with warning messages which shouldn't be warnings as it's a normal behavior 1) When no database is connected we log "warning invalid ssl certificate" 2) When no database is connected we log "warning odoo server not set" I log both as info level to still keep this information but avoid spamming useful error logs with it

Here is a little test to check the onchange for multiple unlinks ### Steps to reproduce: - Create a storable product SP tracked by serial number - Register 3 serial numbers SN01, SN02 and SN03 in stocks for that product (this can for instance be achieved by creating and validating a receipt where you assigned the serial numbers) - Create a delivery order for these 3 units and mark as to do - "Extend" the stock move of the picking to see the serial numbers, remove two of them of then and save ### Expected behavior: The last serial number remains assigned to the stock move ### Current behavior: The quantity set on the stock move is zero and hence saving the record will remove all associated stock move line and hence every remaining SN Cause of the issue: The "lot_ids" field of the stock.move model is a computed non-stored many2many field. The first time we remove an SN, an onchange setting the "lot_ids" of the stock move is performed and correctly updates the new record both in terms of quantity and lots/stock.move.line. On the other hand, the second time that we remove a serial number, the onchange tries to modify two times the SN linked to our move. Once by modifying the "lot_ids" of the "move_ids_without_package" of the picking with an "update" command and once more by modifying the dirrectly the "lot_ids" of stock move with two unlink (the previous one and the current one). However, the first of these update will incorrectly set the "lot_ids" to an empty value in the cache since, to not modify the "move_ids_without_package" directly on "real" record, a "new" picking will be created to update the cache: https://github.com/odoo/odoo/blob/b11480e757ba35e0c616b84bf4dd801210de66f0/addons/web/models/models.py#L1030 However, during this call of the "new" method, the cache is updated again: https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/models.py#L6436-L6437 but this time with the validate parameter equal to false ! During this call, the lot_ids of the the stock move of the "new"picking will be updated using the ids provided by the "convert_to_cache" method here: https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/models.py#L6003-L6004 However, the convert_to_cache method of multirelational field, clears all the ids of an unlink operation in case validate is set to false because of these lines: https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/fields.py#L4207 https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/odoo/fields.py#L4220-L4221 As a result, the lot_ids of the stock_move is set to be empty in cache. Soon after the "_onchange_lot_ids" method is triggered to compute the quantity linked of products related to the stock.move: https://github.com/odoo/odoo/blob/c6ddaeaf2a6ae70df7f36a1cbc3a874d58ca0b88/addons/stock/models/stock_move.py#L1121-L1123 Since the lot_ids is set to an empty record set in cache, this value is used and a quantity of 0 is set. As such, the stock move line linked to the move will be unlinked to the move when a save is performed. ### Note: This flow use to work correctly as, before 17.0, the command set was used instead of unlink to perform the changes on the lot_ids. This has been changed by the following commit: https://github.com/odoo/odoo/commit/e4b66668e0ff3d5444ef7fc7b79e6226c513e2c0 opw-3897055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr