Wednesday, April 2, 2025
2 changes · 17.0
Resolved issues and error corrections
This fixes an error that could block saving partner records when switching a partner's linked company in a multi-company setup. Existing company-specific partner settings are cleared before being copied again, preventing duplicate records and improving reliability for users managing shared commercial partners.
Original PR description
Versions -------- - 17.0 - saas-17.4 Commit de302c2d3630 removed the `ir.property` model in 18.0+ Steps ----- 1. Have 2 companies; 2. set a payment term on a commercial partner; 3. switch to other…
Versions -------- - 17.0 - saas-17.4 Commit de302c2d3630 removed the `ir.property` model in 18.0+ Steps ----- 1. Have 2 companies; 2. set a payment term on a commercial partner; 3. switch to other company; 4. create a partner with commercial partner as their company & save; 5. remove the commercial partner & save; 6. re-add the commercial partner & save. Issue ----- > The operation cannot be completed: duplicate key value violates unique constraint "ir_property_unique_index" > DETAIL: Key (fields_id, COALESCE(company_id, 0), COALESCE(res_id, ''::character varying))=(7155, 1, res.partner,381799) already exists. Cause ----- Commit 7690479 added the `_company_dependent_commercial_sync` method to sync properties between partners & their commercial partners. It does this by looking for properties that exist from companies other than the current one, and attempts to copy them. When copying them, it's possible it attempts to create a duplicate key. Solution -------- Unlink existing properties for the current partner before copying new ones. opw-4679276
This fixes Amazon offer handling when a product’s fulfilment channel changes, so outdated offer details are cleared and refreshed later. It helps prevent incorrect stock updates and reduces the risk of Amazon ghost listings that can route orders through the wrong fulfilment channel.
Original PR description
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this…
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer. While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0. When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer. As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again. opw-4681035