Monday, November 3, 2025
3 changes · 17.0
Resolved issues and error corrections
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916
Issue ----- When providing multiple SN on the reception form, only the first one is used for the original production, the backorders SN are instead automatically generated. Steps to reproduce ----- - Create a subcontracted produt tracked by serial number - Create a purchase for 2 units of the subcontracted product & confirm - Open reception and create 2 SNs for the product & save the form > Only the first SN is used, the second got replaced by a generated one Cause ----- When sa
Original PR description
Issue ----- When providing multiple SN on the reception form, only the first one is used for the original production, the backorders SN are instead automatically generated. Steps to reproduce ----- -…
Issue ----- When providing multiple SN on the reception form, only the first one is used for the original production, the backorders SN are instead automatically generated. Steps to reproduce ----- - Create a subcontracted produt tracked by serial number - Create a purchase for 2 units of the subcontracted product & confirm - Open reception and create 2 SNs for the product & save the form > Only the first SN is used, the second got replaced by a generated one Cause ----- When saving the form, we write on both the SM's `quantity` and `lot_ids`. This triggers the inverse `set_lot_ids` which updates the SMLs accordingly https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/stock/models/stock_move.py#L560 But after `lot_ids` inverse, we trigger the `quantity` one, which calls the move's `_auto_record_components` https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L85 where we split the production. https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L97-L101 The production is split into N productions for a single unit of the product (because the `lot_producing_id` field of the MO is a many2one, see https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp/models/mrp_production.py#L78-L80 Once the production has been split, a `lot_producing_id` is assigned to the backorder productions by calling `action_generate_serial`. https://github.com/odoo/odoo/blob/66ad67dfffbd2796f3115ddf9c0aa71d3f0d3c7e/addons/mrp_subcontracting/models/stock_move.py#L103-L106 We could instead assign the unused ids in the SM's `lot_ids` to the backorder productions. ----- Ticket: opw-5003930
This change prevents stopped call ringtones from being restarted accidentally using media keys after the call has ended. It helps avoid unexpected audio playback and makes call handling behave more predictably for users.
Original PR description
Before this commit, users can resume "stopped" ringtones by pressing the Media Play/Pause key of their keyboard/headphones, even after the call has ended. After this commit, stopping the ringtone clears the audio source, effectively preventing it from being resumed. Task-5222704 opw-5186087