[FW][FIX] stock: avoid recomputing the schedule_date too early #143570
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
|
@clesgow @amoyaux cherrypicking of pull request #143377 failed. stdout: stderr: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?). In the former case, you may want to edit this PR message as well. More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
robodoo
added
forwardport
clesgow
force-pushed
the
16.0-15.0-fix-picking-date-recompute-quwo-dflR-fw
branch
from
3146a29 to
ec17e81
Compare
clesgow
force-pushed
the
16.0-15.0-fix-picking-date-recompute-quwo-dflR-fw
branch
3 times, most recently
from
c8f4420 to
d50208d
Compare
|
robodoo r+ |
|
@clesgow @amoyaux @Whenrow staging failed: ci/runbot on 03f7348fb602a28dc5c2fadc95d994ef124d193c (view more at https://runbot.odoo.com/runbot/build/54805061) |
Steps to reproduce: - Inventory -> Delivery -> New Planned transfer - Add two lines with two different products and save - Set different scheduled dates for each move - Set the earliest move quantity_done to the demand - Validate and create a backorder Issue: The done picking scheduled date will be changed to the latest move (that is moved to the backorder). This is due to a recompute of the picking's scheduled_date *before* the remaining moves are assigned to the backorder. Note: The order on the `stock.move.line` had to be removed, as it forced a recompute of the original picking *before* the assignation of the remaining moves to the backorder. What happens is : - Updating the move will check its move lines - To follow the SML order, it will need their pickings - To follow the picking order, it will need their scheduled date - Their scheduled dates can be out of date (since we already put some moves to `done`) - This will lead to a recompute of the original picking's scheduled date Instead, what we do is adapt the changes from odoo#79069, moving the order from the model to the reports where it's used. opw-3346598 X-original-commit: c505d0d
clesgow
force-pushed
the
16.0-15.0-fix-picking-date-recompute-quwo-dflR-fw
branch
from
d50208d to
c208230
Compare
|
robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
Dec 14, 2023
Steps to reproduce: - Inventory -> Delivery -> New Planned transfer - Add two lines with two different products and save - Set different scheduled dates for each move - Set the earliest move quantity_done to the demand - Validate and create a backorder Issue: The done picking scheduled date will be changed to the latest move (that is moved to the backorder). This is due to a recompute of the picking's scheduled_date *before* the remaining moves are assigned to the backorder. Note: The order on the `stock.move.line` had to be removed, as it forced a recompute of the original picking *before* the assignation of the remaining moves to the backorder. What happens is : - Updating the move will check its move lines - To follow the SML order, it will need their pickings - To follow the picking order, it will need their scheduled date - Their scheduled dates can be out of date (since we already put some moves to `done`) - This will lead to a recompute of the original picking's scheduled date Instead, what we do is adapt the changes from #79069, moving the order from the model to the reports where it's used. opw-3346598 closes #143570 X-original-commit: c505d0d Related: odoo/enterprise#52795 Signed-off-by: Arnold Moyaux (arm) <[email protected]> Signed-off-by: William Henrotin (whe) <[email protected]>
This was referenced Dec 14, 2023
ticodoo
added a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 20, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view
robodoo
pushed a commit
that referenced
this pull request
Dec 20, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #146963 Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 20, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view X-original-commit: 79f12ed
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 20, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view X-original-commit: 79f12ed
robodoo
pushed a commit
that referenced
this pull request
Dec 21, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147016 X-original-commit: 79f12ed Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Tiffany Chang (tic) <[email protected]>
robodoo
pushed a commit
that referenced
this pull request
Dec 21, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147005 X-original-commit: 79f12ed Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Tiffany Chang (tic) <[email protected]>
ticodoo
added a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 21, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view X-original-commit: 79f12ed
robodoo
pushed a commit
that referenced
this pull request
Dec 21, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147025 X-original-commit: 79f12ed Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Tiffany Chang (tic) <[email protected]>
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 21, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view X-original-commit: 8df5d82
This was referenced Dec 21, 2023
robodoo
pushed a commit
that referenced
this pull request
Dec 22, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147178 X-original-commit: 8df5d82 Signed-off-by: Tiffany Chang (tic) <[email protected]> Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
ticodoo
added a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 27, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view
robodoo
pushed a commit
that referenced
this pull request
Dec 27, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147188 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Tiffany Chang (tic) <[email protected]>
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Dec 27, 2023
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view X-original-commit: b53d3cd
robodoo
pushed a commit
that referenced
this pull request
Dec 27, 2023
Previous PR #143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes #147562 X-original-commit: b53d3cd Signed-off-by: Tiffany Chang (tic) <[email protected]> Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
luanjubica
pushed a commit
to luanjubica/odoo-code
that referenced
this pull request
Feb 14, 2024
Steps to reproduce: - Inventory -> Delivery -> New Planned transfer - Add two lines with two different products and save - Set different scheduled dates for each move - Set the earliest move quantity_done to the demand - Validate and create a backorder Issue: The done picking scheduled date will be changed to the latest move (that is moved to the backorder). This is due to a recompute of the picking's scheduled_date *before* the remaining moves are assigned to the backorder. Note: The order on the `stock.move.line` had to be removed, as it forced a recompute of the original picking *before* the assignation of the remaining moves to the backorder. What happens is : - Updating the move will check its move lines - To follow the SML order, it will need their pickings - To follow the picking order, it will need their scheduled date - Their scheduled dates can be out of date (since we already put some moves to `done`) - This will lead to a recompute of the original picking's scheduled date Instead, what we do is adapt the changes from odoo#79069, moving the order from the model to the reports where it's used. opw-3346598 closes odoo#143570 X-original-commit: c505d0d Related: odoo/enterprise#52795 Signed-off-by: Arnold Moyaux (arm) <[email protected]> Signed-off-by: William Henrotin (whe) <[email protected]>
luanjubica
pushed a commit
to luanjubica/odoo-code
that referenced
this pull request
Feb 14, 2024
Previous PR odoo#143570 moved some move line ordering logic from the model to the view to avoid recomputing of these fields since it was causing issues with the computes occurring at the wrong time. Unfortunately every field used in the `default_order` in the view has to be present in the view and since v16 any fields that have a groups attribute that isn't met isn't loaded in the view. Therefore we have to force the `result_package_id` to always be in the view even if `stock.group_tracking_lot` is not true (i.e. packages are active) Steps to reproduce: - create +save a receipt with a tracked product - click on the burger button to open the detailed operations of the tracked product - add 2 move lines + Confirm Expected behavior: the move lines save Actual behavior: JS traceback due to trying to sort on a field that isn't present in the view closes odoo#146963 Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Steps to reproduce:
Issue:
The done picking scheduled date will be changed to the latest move (that is moved to the backorder).
This is due to a recompute of the picking's scheduled_date before the remaining moves are assigned to the backorder.
opw-3346598
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: #143417
Forward-Port-Of: #143377