Tuesday, February 11, 2025
6 changes · 17.0
Resolved issues and error corrections
Manufacturing orders now include the right component lines when a bill of materials is updated with a kit product variant. This prevents missing consumables, such as variant-specific materials, so production requirements stay accurate after BOM changes.
Original PR description
Issue ----- When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables. Steps to…
Issue
-----
When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables.
Steps to reproduce
-----
- Install Manufacturing app
- Create a BoM for the "T-Shirt" product
- Add a "Logo" product as a consumable
- Create a "Fabric" product, with "Material" Attribute with values "P" & "C"
- Create a BoM for the "Fabric" product
- Set Bom Type to "Kit"
- Add a "Thread" product as a consumable
- Add a "Polyester" product as a consumable for variant "P"
- Add a "Coton" product as a consumable for variant "C"
- Create a Manufacturing Order for "T-Shirt"
- Confirm the MO
- Open the BoM (click the link in the form)
- Add "Fabric (C)" as a component to the BoM
- Go back to the MO and click "Udate BoM"
-> There is no line for the consumption of "Coton" from the "Fabric" BoM
Cause
-----
The _link_bom method filters the bom_lines to keep based on the attributes of the final product only, instead of the bom_line's intermediate product.
-----
Ticket:
opw-4480039Bulk editing task assignees could fail when the same task appeared more than once in a grouped list, such as under multiple tags. This fix prevents duplicate follower entries from being created, so users can update assignees in batch without hitting an error.
Original PR description
Steps to reproduce: ------------------- 1. Install the Project App 2. Create a new task with two tags 'Tag A' and 'Tag B' 3. Go in the list view and group by tags 4. Select twice the same task (once…
Steps to reproduce: ------------------- 1. Install the Project App 2. Create a new task with two tags 'Tag A' and 'Tag B' 3. Go in the list view and group by tags 4. Select twice the same task (once in group 'Tag A' and the other in group 'Tag B') 5. Add an assignee to the tasks (in batch) 6. A constraint is triggered: "Error, a partner cannot follow twice the same object." Fix: ------------------- This constraint is triggered because we try to add twice the same follower to the same task at this line: https://github.com/odoo/odoo/blob/17.0/addons/mail/models/mail_thread.py#L4192 as we have "self" being a recordset containing twice the same task record (e.g. project.task(1,1)). This seems to be a generic issue as it could also occur for helpdesk tickets for instance, where we also have assignees that we can modify in batch. And probably other models are affected too. So the fix was done in mail for this purpose. The fix consists to filter the duplicate records in self, in order to avoid creating multiple 'mail.followers' having the exact same (res_model,res_id,partner_id) combination, which leads to the SQL constraint error "mail_followers_res_partner_res_model_id_uniq". task-3978491 version-17.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes company validation so records linked through one-to-many or many-to-many fields are all checked, not just one matching record. It helps prevent data from being incorrectly connected across incompatible companies, reducing multi-company data consistency issues.
Original PR description
Previously, the company check on a relational field was ensuring that at least one of the related records had a compatible company. This worked fine for many2one fields, which have a single related record, but not for one2many and many2many fields, which can have multiple related records (only one of them needed to have a compatible company for the check to succeed). This fix rewrites the company check to ensure that none of the related records have an incompatible company.
Chilean electronic receipts with related documents now generate data that matches the government-required format. This prevents validation failures when submitting Boleta Electronica documents to the Chilean tax authority.
Original PR description
In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap it with the appropriate envelope. However the schema of Boletas slighly differs[1], as it doesn't have the field FchRef, so it gets rejected by SII A solution is to modify the code of dte_subtemplate to make sure that FchRef only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd, and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd [1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf opw-4433202
Receipt validation now creates quality checks only for the items that were actually picked. This prevents users from being asked to process unnecessary checks for products left for a backorder, reducing confusion and extra work.
Original PR description
Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
- Tracked by Serial Number
- Create a quality control point:
- Operation: Receipt
- Control per: Quantity
- Create a receipt:
- 10 units of P1
- 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
- Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.
Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.
Expected Behavior:
Quality checks should only be triggered for picked moves
opw-4442564This fix ensures the barcode app includes relevant archived location records when preparing its data cache. Users can now open affected inventory transfers without the app crashing when an archived parent location is involved.
Original PR description
### Issue: The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are…
### Issue: The barcode relies heavily on the data fetched in its LazyCache to work properly (in order to avoid rpc call's each time records data's are needed). However, some of these data's are loaded using search methods that ignore archived records by default. This leads to the creation of a cache that do not contains records that are expected to be there and hence will lead to tracebacks. ### Steps to reproduce: - In the settings enable "Multi-Step Routes" - Inventory > Configuration > Warehouse Management > Locations - Create a new location WH/Stock/Love and a children location WH/Stock/Love/Layer - Create and confirm an internal transfer from WH/Stock to WH/Stock/Love for 1 unit of any storable product in stock - Change the location dest of the move line to WH/Stock/Love/Layer. - Archive the location WH/Stock/Love - Open your internal transfer in the barcode App. #### > Traceback: An error occured in the owl lifecycle... Record stock.location with id=... doesn't exist in the cache, it should return by the server at LazyBarcodeCache.getRecord. ### Cause of the issue: When entering the barcode man component, a call of the `get_barcode_data` is launched to fetch and populate the barcode data's and data are added to the barcode lazy cache in order to retreive record values without additional rpc calls: https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/main.js#L76-L93 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_model.js#L32-L34 For instance, when redering the picking template, the location dest id will be retreived from the cache: https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/components/line.js#L7-L9 https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/static/src/models/barcode_picking_model.js#L1077-L1079 The traceback occurs because the record was actually never added to the data's and hence never added to the cache because part of the `get_barcode_data` call is performed with searchs that ignore completely the archived records (unless the 'active_test' key is in the context): https://github.com/odoo/enterprise/blob/cc21959226e0bdb6b840f5023f08b2fdc0590023/stock_barcode/models/stock_picking.py#L102-L106 opw-4423110