This reverts commit 768f186fd2.
Which is not more optimized, the optimization based on parent_path
doesn't make sense here as the ORM will read parent_path in the location
and get the parent ids by splitting the ids, it doesn't need more than
one query on stock_location which is done based on its id and can reuse
the cache, there is no lookup on parent path for parent_of.
>>> env["stock.reserve.rule"].search([("location_id", "parent_of", 3125)])
2020-05-27 05:36:59,938 1 DEBUG log_p odoo.sql_db: query: SELECT "stock_location"."id" as "id","stock_location"."name" as "name","stock_location"."complete_name" as "complete_name","stock_location"."active" as "active","stock_location"."usage" as "usage","stock_location"."location_id" as "location_id","stock_location"."comment" as "comment","stock_location"."parent_path" as "parent_path", <stripped>,"stock_location"."create_uid" as "create_uid","stock_location"."create_date" as "create_date","stock_location"."write_uid" as "write_uid","stock_location"."write_date" as "write_date" FROM "stock_location" WHERE "stock_location".id IN (3125)
2020-05-27 05:36:59,942 1 DEBUG log_p odoo.sql_db: query: SELECT "stock_reserve_rule".id FROM "stock_reserve_rule" WHERE (("stock_reserve_rule"."active" = true) AND ("stock_reserve_rule"."location_id" in (1,7,8,133,134,135,144,207,3125))) ORDER BY "stock_reserve_rule"."sequence" ,"stock_reserve_rule"."id"
It could not work properly here as we need the "fallback" to apply
even if there is no quantity at all in the stock. As we hook the
reservation rules in StockMove._update_reserved_quantity(), and
this method is called only if we have at least 1 product in qty,
the fallback was not applied with zero qty.
A new module will handle this concept: https://github.com/OCA/wms/pull/28
Example of configuration:
Rule location: Stock
Removal rule 1: Stock/Zone1
Removal rule 2: Stock/Zone2
Reservation of a stock move with Stock/Zone2 as source location.
Previously, it would reserve in Stock/Zone1.
Now, it will never be allowed to reserve in Stock/Zone1.
A warning message was added previously to warn the user about potential
issues, which is now obsolete so I removed it.
Before the change, the implementation of the fallback goes like this:
If I reserve a move of 3000 and it finds 600 units, it splits the move
to create a new move of 2400 and pretend to the caller that 3000 was
reserved so the initial move is changed to 'assigned'.
Now, if we have a move of 2400 and finds zero, it still splits the move,
and pretend to the caller that 2400 was reserved → the initial move has
no move line but is assigned. In this case, we should not split the move
but only update the source location of the move.
