[15.0] [FIX] stock_picking_propagate_scheduled_date: recursion error

[ivantodorovich]

Depending on the installed modules, their resolution order (MRO), and the moves relationships through their move_dest_ids and move_orig_ids fields, we could get into a situation where the very same move that triggered the propagation gets propagated twice (or more) in the same transaction.

This happens because the modified context, which we use to keep track of the already propagated moves, is only available down the stack, and it's lost once we exit the method. However, other modules might also react to the changes and trigger other kinds of propagations, which might lead to our original record being propagated again.

This is the case with the core mrp_subcontracting module, which propagates the move's date to the related manufacturing order's date_planned_start and date_planned_finished fields. Which, in turn, triggers the propagation of these two fields to their related move_raw_ids and move_finished_ids.

It can just so happen that one of these related moves also points to our original move in their move_dest_ids or move_orig_ids fields chain.

The solution relies on the _register_hook method, which gets executed after the model has been initialized, and so it's able to patch the write method getting a top position in the stack, and inject the context key there.

---

Superseeds https://github.com/OCA/stock-logistics-workflow/pull/1644

@gurneyalex @SilvioC2C @vvrossem @yankinmax

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[gurneyalex]

@ivantodorovich I updated your PR with 2 new commits:

• avoid calling _propagate_date when self is an empty recordset
• better fix in case a backorder is created and mrp_subcontracting is installed