Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[15.0][MIG] stock_reserve_rule: Migration to 15.0. #1753

Merged
merged 37 commits into from
Jul 11, 2023

Conversation

Ricardoalso
Copy link
Contributor

No description provided.

guewen and others added 30 commits June 12, 2023 14:30
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.
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.
Searching all rules then filtering in python the parent path is
more efficient than finding all the parent locations and finding
the matching rules.
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: OCA/wms#28
As the logger outputs an error log during tests, travis counts it as a
failure of a test.
This reverts commit 768f186.

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"
When rules are configured and have been applied, we should not
have an implicit fallback on the base location, as it would kind
of cancel the benefits of the rules (as it would then take whatever
it wants anywhere in all the locations).
The rules created in demo data of stock_reserve_rule make the tests of
stock_vertical_lift (and possibly other modules) fail because the
transfers can't be made available.

Deactivate the rule in stock_reserve_rule and activate it only in its
tests. Users can still activate the rule manually to test.
The former implementation was sorting the quants per location and trying
to take as much quantities as possible from the same locations, to limit
the number of operations to do. Then, only, removal order (fifo, ...)
was applied. It is more important to respect removal order than limiting
the operations, so remove this "optimization".
The former implementation was to take as much as possible of the largest
packaging, to the smallest packacking, to have less to move.
Then, only, removal order (fifo, ...) was applied for equal quantities.
It is more important to respect removal order than limiting the
operations, so remove this "optimization".
To remove the duplicate implementation of
StockLocation.is_sublocation_of()
@Ricardoalso Ricardoalso mentioned this pull request Jun 12, 2023
80 tasks
@Ricardoalso Ricardoalso force-pushed the 15.0-mig-stock_reserve_rule branch from 246f774 to 4524ecf Compare June 12, 2023 13:02
@Ricardoalso Ricardoalso force-pushed the 15.0-mig-stock_reserve_rule branch from c197168 to 13a4bc2 Compare June 21, 2023 07:14
@rousseldenis
Copy link
Contributor

/ocabot migration stock_reserve_rule

Copy link
Contributor

@rousseldenis rousseldenis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review

@Ricardoalso Ricardoalso force-pushed the 15.0-mig-stock_reserve_rule branch from 13a4bc2 to 8c3fb8f Compare June 21, 2023 07:39
@OCA-git-bot
Copy link
Contributor

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). 🤖

@dreispt
Copy link
Member

dreispt commented Jul 4, 2023

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

What a great day to merge this nice PR. Let's do it!
Prepared branch 15.0-ocabot-merge-pr-1753-by-dreispt-bump-nobump, awaiting test results.

OCA-git-bot added a commit that referenced this pull request Jul 4, 2023
Signed-off-by dreispt
@OCA-git-bot
Copy link
Contributor

@dreispt your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-1753-by-dreispt-bump-nobump.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

@leemannd
Copy link

It seems the pre-commit test has been killed during the merge -> https://github.com/OCA/stock-logistics-warehouse/actions/runs/5455628789/jobs/9927342186

@dreispt
Copy link
Member

dreispt commented Jul 11, 2023

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 15.0-ocabot-merge-pr-1753-by-dreispt-bump-nobump, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit f0f9b9d into OCA:15.0 Jul 11, 2023
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at c488165. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.