[18.0][FIX] mrp: location_dest_id with the MRP module installed.

[angelgarciadelachica]

Summary

This PR fixes the pre-migration script for the MRP module in version 18 by adjusting the calculation of location_dest_id to consider inheritance and the custom logic applied by the Manufacturing (MRP) module.

Problem Description

The current pre-migration script for the stock module to v18 renames location_dest_id to location_final_id and recalculates location_dest_id using the standard stock.move queries (based on _compute_location_dest_id()).

However, this logic is incomplete when the mrp module is installed, since this module overrides the _compute_location_dest_id() method. Currently, there is no mechanism in place to handle this scenario, resulting in an incorrect location_dest_id in stock movements generated from a production order.

To Reproduce

1. Perform a database migration from v17 to v18 with MRP installed.
2. Examine an existing manufacturing order (MO) in the source version:

4. Verify the stock movements generated by that MO:

5. In v18, review the stock movement history. You will notice that location_dest_id has not been migrated correctly. The expected behavior, following the logic for creating an MO in v18, should be different:

@HaraldPanten @ValentinVinagre
I-8773

[pedrobaeza]

If the moves were generated in 17, they should contain already the correct destination location. Can you point where in OpenUpgrade they are being changed back to WH/Stock?

[angelgarciadelachica]

Thanks for your reply! :-)

In the Stock pre-migration script:

1. Rename the old location_dest_id to location_final_id
2. Then create a new location_dest_id, which is populated by fill_stock_move_location_dest_id() using the logic from _compute_location_dest_id().
   The problem is that the migration script does not take into account the inherited logic from the mrp module -> _compute_location_dest_id().