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_move_auto_assign: Migration to 15.0 #1799

Closed
wants to merge 16 commits into from

Conversation

kaynnan
Copy link
Contributor

@kaynnan kaynnan commented Jul 18, 2023

guewen and others added 16 commits July 18, 2023 08:57
Automatically check availability of stock moves when a move is set to "done".

It uses queue jobs to verify the availability in order to have a minimal impact
on the user operations.

The conditions to trigger the check are:

* A move is marked as done
* The destination locations of the move lines are internal
* The move doesn't have successors in a chain of moves

At this point, jobs are generated:

* One job per product
* Any move waiting for stock in a parent (or same) location of the internal
  destination locations from the done move has its availability checked

Only one job is generated for an identical set of (product, locations).
When the 2 last moves of a stock.picking are assigned at the same
time by 2 jobs (different products both available), none of the
transaction will see that it is the last move to be assigned. As a
result, the picking will stay in state "confirmed" even if all its
moves are assigned.

Lock the stock.picking records when we call auto_assign.
If we have many pickings touched for the same product, the lock
can be quite large, so we may have to find a better option.

I could not write a test to exercise this, because we can't have 2
transactions being aware of it, even if we create the picking in demo
data as tests can be run during install.
Following changes in OCA/queue#274
This module is being backported from v16, related PR:

* OCA#1560
@kaynnan kaynnan marked this pull request as ready for review July 18, 2023 13:04
@marcelsavegnago
Copy link
Member

@augustodinizl @aug1804 can you review please?

Copy link

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Mar 10, 2024
@github-actions github-actions bot closed this Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants