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?
* \[open\] Should we add an explicit lag to have the same behaviour as work packages?
* \[open\] When decreasing a date, will the successor's dates be decreased as well?
* \[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\] What to do on empty successors
* \[open\] What to do on empty predecessors
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.
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.
**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?
* \[open\] Should we add an explicit lag to have the same behaviour as work packages?
* \[open\] When decreasing a date, will the successor's dates be decreased as well?
* \[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\] What to do on empty successors
* \[open\] What to do on empty predecessors
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.
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.