[FIX] mrp: keep end time and duration consistent when moving work order #97805
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
|
|
MerlinGuillaume
force-pushed
the
13.0-opw-289362-workorder_duration_drag_and_drop-megu
branch
2 times, most recently
from
db42299
to
a365330
Compare
MerlinGuillaume
force-pushed
the
13.0-opw-289362-workorder_duration_drag_and_drop-megu
branch
2 times, most recently
from
5fd2434
to
8cc5c11
Compare
MerlinGuillaume
changed the title
MerlinGuillaume
force-pushed
the
13.0-opw-289362-workorder_duration_drag_and_drop-megu
branch
from
8cc5c11
to
e2b26d9
Compare
Whenrow
reviewed
Aug 22, 2022
addons/mrp/models/mrp_workorder.py
Outdated
| @@ -349,6 +355,16 @@ def write(self, values): | |||
| end_date = fields.Datetime.to_datetime(values.get('date_planned_finished')) or workorder.date_planned_finished | |||
| if start_date and end_date and start_date > end_date: | |||
| raise UserError(_('The planned end date of the work order cannot be prior to the planned start date, please correct this to save the work order.')) | |||
| if 'duration_expected' not in values: | |||
| if 'date_planned_start' in values and 'date_planned_finished' in values: | |||
| computed_finished_time = self._compute_date_planned_finished(start_date) | |||
There was a problem hiding this comment.
Could you rename the method. It can be confusing with actual compute methods
There was a problem hiding this comment.
Done ! Changed 'compute' to 'calculate'
There was a problem hiding this comment.
Hello @Whenrow, are you okay with this PR now ?
When drag and dropping a work order in the Work Orders Planning, the end time wasn't recomputed. This can make the end time inconsistent with the duration when the work order spans across a non-working time. Steps to reproduce: 1. Install Manufacturing 2. Go to Settings > Manufacturing > Operations and enable Work Orders 3. Go to Manufacturing > Master Data > Routings and edit routing 'Primary Assembly' to last 120:00 minutes 4. Go to Manufacturing > Operations > Manufacturing Orders and create one with values: - Product: Table Top - Plan From: today's date at 11:00:00 5. Save, mark as todo and plan the manufacturing order 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. Move the work order to 8 am 8. The work order still lasts for 3 hours (according to its start and finish time) even though its expected duration is 2 hours Solution: Recompute `date_planned_finished` when we move a work order in the planning (`date_planned_start` and `date_planned_finished` are passed in values), and recompute `expected_duration` when we extend it (only one of them is passed depending on the way we extend the work order). (`duration_expected` is never passed in values when we manipulate a work order through the planning) Problem: `date_planned_finished` wasn't recomputed when moving the work order in the planning opw-2893622
MerlinGuillaume
force-pushed
the
13.0-opw-289362-workorder_duration_drag_and_drop-megu
branch
from
e2b26d9
to
562058b
Compare
|
robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
Sep 19, 2022
When drag and dropping a work order in the Work Orders Planning, the end time wasn't recomputed. This can make the end time inconsistent with the duration when the work order spans across a non-working time. Steps to reproduce: 1. Install Manufacturing 2. Go to Settings > Manufacturing > Operations and enable Work Orders 3. Go to Manufacturing > Master Data > Routings and edit routing 'Primary Assembly' to last 120:00 minutes 4. Go to Manufacturing > Operations > Manufacturing Orders and create one with values: - Product: Table Top - Plan From: today's date at 11:00:00 5. Save, mark as todo and plan the manufacturing order 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. Move the work order to 8 am 8. The work order still lasts for 3 hours (according to its start and finish time) even though its expected duration is 2 hours Solution: Recompute `date_planned_finished` when we move a work order in the planning (`date_planned_start` and `date_planned_finished` are passed in values), and recompute `expected_duration` when we extend it (only one of them is passed depending on the way we extend the work order). (`duration_expected` is never passed in values when we manipulate a work order through the planning) Problem: `date_planned_finished` wasn't recomputed when moving the work order in the planning opw-2893622 closes #97805 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This was referenced Sep 19, 2022
|
@MerlinGuillaume @Whenrow this pull request has forward-port PRs awaiting action (not merged or closed): |
MerlinGuillaume
added a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 29, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them)
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 30, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) X-original-commit: 26cb902
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 30, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) X-original-commit: 26cb902
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 30, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) X-original-commit: 26cb902
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 30, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) X-original-commit: 26cb902
fw-bot
pushed a commit
to odoo-dev/odoo
that referenced
this pull request
Sep 30, 2022
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) X-original-commit: 26cb902
robodoo
pushed a commit
that referenced
this pull request
Sep 30, 2022
This PR #97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes #101750 X-original-commit: 26cb902 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Sep 30, 2022
This PR #97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes #101775 X-original-commit: 26cb902 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Sep 30, 2022
This PR #97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes #101742 X-original-commit: 26cb902 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Sep 30, 2022
This PR #97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes #101728 X-original-commit: 26cb902 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
robodoo
pushed a commit
that referenced
this pull request
Oct 1, 2022
This PR #97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes #101761 X-original-commit: 26cb902 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
fw-bot
deleted the
13.0-opw-289362-workorder_duration_drag_and_drop-megu
branch
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Jan 11, 2023
When drag and dropping a work order in the Work Orders Planning, the end time wasn't recomputed. This can make the end time inconsistent with the duration when the work order spans across a non-working time. Steps to reproduce: 1. Install Manufacturing 2. Go to Settings > Manufacturing > Operations and enable Work Orders 3. Go to Manufacturing > Master Data > Routings and edit routing 'Primary Assembly' to last 120:00 minutes 4. Go to Manufacturing > Operations > Manufacturing Orders and create one with values: - Product: Table Top - Plan From: today's date at 11:00:00 5. Save, mark as todo and plan the manufacturing order 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. Move the work order to 8 am 8. The work order still lasts for 3 hours (according to its start and finish time) even though its expected duration is 2 hours Solution: Recompute `date_planned_finished` when we move a work order in the planning (`date_planned_start` and `date_planned_finished` are passed in values), and recompute `expected_duration` when we extend it (only one of them is passed depending on the way we extend the work order). (`duration_expected` is never passed in values when we manipulate a work order through the planning) Problem: `date_planned_finished` wasn't recomputed when moving the work order in the planning opw-2893622 closes odoo/odoo#97805 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
gamarino
pushed a commit
to numaes/numa-public-odoo
that referenced
this pull request
Jan 11, 2023
This PR odoo/odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes odoo/odoo#101580 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
zamberjo
pushed a commit
to aurestic/OpenUpgrade
that referenced
this pull request
Mar 1, 2023
When drag and dropping a work order in the Work Orders Planning, the end time wasn't recomputed. This can make the end time inconsistent with the duration when the work order spans across a non-working time. Steps to reproduce: 1. Install Manufacturing 2. Go to Settings > Manufacturing > Operations and enable Work Orders 3. Go to Manufacturing > Master Data > Routings and edit routing 'Primary Assembly' to last 120:00 minutes 4. Go to Manufacturing > Operations > Manufacturing Orders and create one with values: - Product: Table Top - Plan From: today's date at 11:00:00 5. Save, mark as todo and plan the manufacturing order 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. Move the work order to 8 am 8. The work order still lasts for 3 hours (according to its start and finish time) even though its expected duration is 2 hours Solution: Recompute `date_planned_finished` when we move a work order in the planning (`date_planned_start` and `date_planned_finished` are passed in values), and recompute `expected_duration` when we extend it (only one of them is passed depending on the way we extend the work order). (`duration_expected` is never passed in values when we manipulate a work order through the planning) Problem: `date_planned_finished` wasn't recomputed when moving the work order in the planning opw-2893622 closes odoo/odoo#97805 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
zamberjo
pushed a commit
to aurestic/OpenUpgrade
that referenced
this pull request
Mar 1, 2023
This PR odoo/odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes odoo/odoo#101580 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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.
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
'Primary Assembly' to last 120:00 minutes
one with values:
the day view
finish time) even though its expected duration is 2 hours
Solution:
Recompute
date_planned_finishedwhen we move a work order in theplanning (
date_planned_startanddate_planned_finishedare passed invalues), and recompute
expected_durationwhen we extend it (only oneof them is passed depending on the way we extend the work order).
(
duration_expectedis never passed in values when we manipulate a workorder through the planning)
Problem:
date_planned_finishedwasn't recomputed when moving the work order inthe planning
opw-2893622