Content
View differences
Updated by Attila Dombi over 1 year ago
**As** a project portfolio manager
**I want to** have stages and gates adjust automatically based on changes to preceding/succeeding stages and gates
**so that** administration is simpler and less error prone.
**Acceptance criteria**
* \[open\] Are gaps allowed? Answer: Yes.
* \[open\] Should we add an explicit lag to have the same behaviour as work packages?
* \[open\] Are all the scenarios correct?
* \[open\] Do we want to show all the changes in the modal before the user commits?
* \[open\] Do we want to introduce modification by durations?
* If so, can a duration be set independently (without start and end date set)?
* \[open\] How does the transportation of automatic scheduling is displayed on the Gantt chart? ie: The user modifies a date without saving the value, should we also display the rescheduled steps?
* \[open\] - Do we want to introduce modification by durations?
ie: Allow a stage to have a duration without the start and end dates?
It would help with having project stage/gate templates which come with a predefined duration.
Scenarios:
Currently this only describes the backend's behaviour and not what is to happen on the frontend.
* Scenarios where there is a stage/gate with a succeeding stage/gate:
* With dates set on predecessor and successor
* With the predecessor being moved
* into the future
* without any gap between them.
* Expected result: The succeeding stage/gate is moved by the same number of days (start and end date)
* with enough gap to include the moved amount of days.
* Expected result: The gap is eaten up. The successor is not moved. There is now a smaller gap between the two.
* There is a gap between the two stages/gates but not enough to completely take in the changed dates of the predecessor.
* Expected result: The gap is eaten up. The successor is moved by the delta of the changed predecessor's end date and the previous gap. There is no gap in the end.
* into the past
* without any gap between them.
* Expected result: The succeeding stage/gate is moved by the same number of days (start and end date)
* with a gap between the two stages/gates.
* \[open\] Expected result: The succeeding stage/gate is moved by the same number of days (start and end date). The gap continues to exist with the same number of days between predecessor and successor.
* With the successor being moved
* into the future.
* Expected result: A gap is added between predecessor and successor. The predecessor is not moved.
* into the past.
* There is no gap.
* Expected result: The successor cannot be moved as that would conflict with the predecessor. An error is displayed.
* There is a gap.
* Expected result: The successor can be moved as long as the change is smaller than the gap. The gap gets eaten up.
* With dates only on the predecessor. Successor does not have dates set.
* With the predecessor being moved
* into the future
* \[open\] Expected result: The dates of the successor are not set
* into the past
* \[open\] Expected result: The dates of the successor are not set
* With the successor receiving dates
* after the predecessor's dates
* Expected result: The successor receives those dates. There may be a gap between the predecessor and the successor. The predecessor is unchanged.
* before/overlapping the predecessor's dates
* \[open\] Expected result: An error is displayed. The successor's dates cannot be saved. The predecessor is unchanged.
<br>
Note from Attila: The current implementation allows overlap between a stage and a gate, but not between LifeCycleEvents of the same type.
* With dates only on the successor. Predecessor has no dates set.
* With the successor being moved
* into the future
* Expected result: The successor is moved. The predecessor does not receive any dates.
* into the past
* Expected result: The successor can be moved. The predecessor does not receive any dates.
* With the predecessor getting dates set
* With the dates being before the successor's dates
* \[open\] Expected result: The successor keeps its dates.
* With the dates overlapping/after the successor's dates
* Expected result: The successor is moved to start on the day after the predecessor's new end date.
* Without any dates set
* Predecessor gets its dates set.
* \[open\] Expected result: The predecessor gets the dates set. The successor does not receive any dates automatically.
* Successor gets its dates set.
* Expected result: The successor gets the dates set. The dates of the predecessor are not set automatically.
* Scenarios where a LifeCycleStep with an existing value is being enabled:
* when the value conflicts with the predecessor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* when the value conflicts with the successor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* Scenarios where the LifeCycleDefinitions are modified:
* When a definition is added:
* Expected result: No rescheduling.
* When a definition is deleted:
* Expected result: No rescheduling.
* When 2 definitions are reordered:
* Reschedule the projects where the affected definitions are enabled and they have dates set.
\[open question\]: Set the new successor to be after the new predecessor maintaining the duration of the predecessor and eating the gap between the two?
Or leave it to the user to solve the validation error? (We agreed to let the user solve the error in <mention class="mention" data-id="60293" data-type="work_package" data-text="#60293">#60293</mention> , but maybe we want to revisit that)
* Scenarios where Non Working days or Non Working weekdays are modified:
* When a Non Working Day or Weekday is added or removed:
* Expected result: No rescheduling.
**I want to** have stages and gates adjust automatically based on changes to preceding/succeeding stages and gates
**so that** administration is simpler and less error prone.
**Acceptance criteria**
* \[open\] Are gaps allowed? Answer: Yes.
* \[open\] Should we add an explicit lag to have the same behaviour as work packages?
* \[open\] Are all the scenarios correct?
* \[open\] Do we want to show all the changes in the modal before the user commits?
* \[open\] Do we want to introduce modification by durations?
* If so, can a duration be set independently (without start and end date set)?
* \[open\] How does the transportation of automatic scheduling is displayed on the Gantt chart? ie: The user modifies a date without saving the value, should we also display the rescheduled steps?
* \[open\] - Do we want to introduce modification by durations?
ie: Allow a stage to have a duration without the start and end dates?
It would help with having project stage/gate templates which come with a predefined duration.
Scenarios:
Currently this only describes the backend's behaviour and not what is to happen on the frontend.
* Scenarios where there is a stage/gate with a succeeding stage/gate:
* With dates set on predecessor and successor
* With the predecessor being moved
* into the future
* without any gap between them.
* Expected result: The succeeding stage/gate is moved by the same number of days (start and end date)
* with enough gap to include the moved amount of days.
* Expected result: The gap is eaten up. The successor is not moved. There is now a smaller gap between the two.
* There is a gap between the two stages/gates but not enough to completely take in the changed dates of the predecessor.
* Expected result: The gap is eaten up. The successor is moved by the delta of the changed predecessor's end date and the previous gap. There is no gap in the end.
* into the past
* without any gap between them.
* Expected result: The succeeding stage/gate is moved by the same number of days (start and end date)
* with a gap between the two stages/gates.
* \[open\] Expected result: The succeeding stage/gate is moved by the same number of days (start and end date). The gap continues to exist with the same number of days between predecessor and successor.
* With the successor being moved
* into the future.
* Expected result: A gap is added between predecessor and successor. The predecessor is not moved.
* into the past.
* There is no gap.
* Expected result: The successor cannot be moved as that would conflict with the predecessor. An error is displayed.
* There is a gap.
* Expected result: The successor can be moved as long as the change is smaller than the gap. The gap gets eaten up.
* With dates only on the predecessor. Successor does not have dates set.
* With the predecessor being moved
* into the future
* \[open\] Expected result: The dates of the successor are not set
* into the past
* \[open\] Expected result: The dates of the successor are not set
* With the successor receiving dates
* after the predecessor's dates
* Expected result: The successor receives those dates. There may be a gap between the predecessor and the successor. The predecessor is unchanged.
* before/overlapping the predecessor's dates
* \[open\] Expected result: An error is displayed. The successor's dates cannot be saved. The predecessor is unchanged.
<br>
Note from Attila: The current implementation allows overlap between a stage and a gate, but not between LifeCycleEvents of the same type.
* With dates only on the successor. Predecessor has no dates set.
* With the successor being moved
* into the future
* Expected result: The successor is moved. The predecessor does not receive any dates.
* into the past
* Expected result: The successor can be moved. The predecessor does not receive any dates.
* With the predecessor getting dates set
* With the dates being before the successor's dates
* \[open\] Expected result: The successor keeps its dates.
* With the dates overlapping/after the successor's dates
* Expected result: The successor is moved to start on the day after the predecessor's new end date.
* Without any dates set
* Predecessor gets its dates set.
* \[open\] Expected result: The predecessor gets the dates set. The successor does not receive any dates automatically.
* Successor gets its dates set.
* Expected result: The successor gets the dates set. The dates of the predecessor are not set automatically.
* Scenarios where a LifeCycleStep with an existing value is being enabled:
* when the value conflicts with the predecessor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* when the value conflicts with the successor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* Scenarios where the LifeCycleDefinitions are modified:
* When a definition is added:
* Expected result: No rescheduling.
* When a definition is deleted:
* Expected result: No rescheduling.
* When 2 definitions are reordered:
* Reschedule the projects where the affected definitions are enabled and they have dates set.
\[open question\]: Set the new successor to be after the new predecessor maintaining the duration of the predecessor and eating the gap between the two?
Or leave it to the user to solve the validation error? (We agreed to let the user solve the error in <mention class="mention" data-id="60293" data-type="work_package" data-text="#60293">#60293</mention> , but maybe we want to revisit that)
* Scenarios where Non Working days or Non Working weekdays are modified:
* When a Non Working Day or Weekday is added or removed:
* Expected result: No rescheduling.