**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.

Begin of the insertion###End of the insertion **Acceptance criteria**

* The duration (added in ##61353) as well as the start and finish dates (added in ##61355) within the project lifecycle administration (reworked in ##61304) are editable.

* \[open\] Either it is always in edit mode or the user first needs to click to turn it into edit mode.

* \[open\] The project start and finish date (introduced in ##61355) needs to follow the same UX pattern.

* Duration can be filled independently from a stages dates.

* The duration can be set independently from the start and end date. In other words, stage might have a duration without having a start/end date set.

* The duration has to be an integer value of at least 1.

* The duration is the number of days a stage includes. Start and end date are included in that interval.

* Stages and gates are automatically (re)scheduled to the extend the information provided by the user allows for.

* See the **Scenarios** section for a detailed specification.

* \[open\] Are all the scenarios correct?

* Automatic scheduling happens as soon as two values out of the three involved attributes (start date, end date & duration) are set (analogous to work packages).

* For gates, as they have a fixed duration of 0 and only one date, that date is the only value that needs to be filled.

* Project start/finish dates behave similar to gates.

* Scheduling a predecessor (by providing two out of the three values, or the one value for a gate), can lead to the successor being rescheduled in turn (e.g. a succeeding stage/gate receives a start date) which can continue as long as each successor is completely specified.

* Since gates and also project finish dates only require a single value to be scheduled, they will always be scheduled once a predecessor is complete.

* Scheduling a successor (by providing two out of the three values, or the one value for a gate), can lead to the predecessor being rescheduled in turn (e.g. a preceding stage/gate receives a finish date) which can continue as long as each successor is completely specified.

* Since gates and also project start dates only require a single value to be scheduled, they will always be scheduled once a successor is complete.

* Stages do not receive a single date when being automatically scheduled. e.g. if a preceding gate is set, the succeeding stage does not receive a start date.

* However, if two values are then available (see above), the stage will be scheduled.

* The reason for this is that stages always require two dates to be defined.

* The date the stage would inherit from its neighbour is displayed in the table (grayed out).

* The date the stage would inherit from its neighbour is preselected in the date picker. The user can choose to select a different value.

* Active stages/gates are considered to be following each other based on the sort order in the administration.

* In case a stage/gate is inactive in a project, the next active stage/gate is considered to be the successor. Multiple inactive stages/gates can be ignored that way.

* Stages/gates not active in the project are not scheduled. In case a stage/gate is inactivated, it keeps its dates.

* The project start date is considered to be the first gate for the sake of automatic scheduling.

* The project finish date is considered to be the last gate for the sake of automatic scheduling.

* Non working days

* Are displayed in the date picker

* Are allowed values for start and end date and do not count towards the duration.

* This is subject to change, see "out of scope".

* Gaps (implicit distance between the end date of a preceding and the start date of a succeeding work package) are not allowed.

* The lag (explicit distance between the end date of a preceding and the start date of a succeeding work package) is for now always 0.

* This is subject to change in a later feature.

* The lag of 0 means

* A stage succeeding another stage will have a start date that is on the next working day relative to the end date of the preceding stage's end date.

* A gate succeeding a stage will have a date that is on the same date as the preceding stage's end date.

* A stage succeeding a gate will have a start date that is on the next working day relative to the date of the preceding stage's date.


Begin of the insertion###End of the insertion **Scenarios**

(Within the scope of the scenarios, when gates are mentioned, this includes the project start and finish date but not the other way around.)

Begin of the insertion#### **IfEnd of the insertion Begin of the deletion **Explanation on scheduling ifEnd of the deletion the dates/duration were not filled completely before**

As stated in the acceptance criteria, scheduling happens when:

* For stages: two out of three values (start date, end date, duration) are set (one might have been set before)

* For gate: the date is set


Since active life cycle steps are always considered to be in a follows relationship, scheduling a step can lead to the successor/predecessor receiving the necessary information to be automatically scheduled in turn. Scheduling can thus propagate both along the line of successors as well as along the line of predecessors. This continues until a stage is met that has then only one value set or until the end of the chain is reached. Gates, since they only require a single value are always continued to be automatically scheduled and will schedule successors/predecessors in turn:

* If scheduling a succeeding gate: Its date will be on the date (for a preceding gate) or the end date (for a preceding stage)

* If scheduling a preceding gate: Its date will be on the date (for a succeeding gate) or one date before the start date (for a succeeding gate)


If a stage is met it will Begin of the insertionreceive :End of the insertion Begin of the deletion receive:End of the deletion

* If scheduling a succeeding stage: Its start date will be 1 day after the date (for a preceding gate) or one 1 day after the end date (for a preceding stage)

* If scheduling a preceding stage: Its end date will be on the date (for a succeed gate) or one day before the start date (for a preceding stage)


Begin of the insertion(\[open\] will the value be persisted in the database in case the stage would end up with only the start or finish date.End of the insertion The Begin of the insertionfontend is to display that date grayed)

TheEnd of the insertion stage thus receiving a start/end date might then have two out of the three necessary values, and will be rescheduled and might continue to schedule in turn:

* If the stage used to have a duration only, it will then get its start/end date calculated:

* start date + (duration - 1)

* end date - (duration - 1)

* If the stage used to have a start/end date only, it will get its duration calculated:

* end date - start date + 1


Begin of the insertion#### **IfEnd of the insertion Begin of the deletion **Explanation on scheduling whenEnd of the deletion date/duration were already provided before**

Begin of the insertionUpdating an alreadyEnd of the insertion Begin of the deletion \[open\] When changing the start/end date of aEnd of the deletion completely Begin of the insertionspecified stage can be done in three ways and each leads to a different rescheduling ofEnd of the insertion Begin of the deletion defined stage, isEnd of the deletion the Begin of the insertionsuccessor/predecessor:End of the insertion Begin of the deletion duration altered or the other date adapted?End of the deletion

Begin of the insertionIfEnd of the insertion Begin of the deletion * The attempt is to do it analogous to work packages. There:

* Duration is decreased ifEnd of the deletion the Begin of the insertionstartEnd of the insertion Begin of the deletion start/dueEnd of the deletion date is Begin of the insertionupdated,End of the insertion Begin of the deletion changed.

* Duration andEnd of the deletion the Begin of the insertiondurationEnd of the insertion Begin of the deletion other dateEnd of the deletion is Begin of the insertionincreased/decreased accordingly. Because aEnd of the insertion Begin of the deletion removed if the start/dueEnd of the deletion date Begin of the insertionrange pickerEnd of the insertion is Begin of the insertionemployed,End of the insertion Begin of the deletion changed to a contradicting value (before/after start/due date)


Scenarios:

Currently this only describesEnd of the deletion the Begin of the insertionuser's intendEnd of the insertion Begin of the deletion backend's behaviour and not whatEnd of the deletion is Begin of the insertionclear.End of the insertion Begin of the deletion to happen on the frontend.

End of the deletion The Begin of the insertionpreceding stages/gatesEnd of the insertion Begin of the deletion scenariosEnd of the deletion are Begin of the insertionupdating accordingly without changing their duration.End of the insertion Begin of the deletion currently being rewritten so this is work in progress.End of the deletion

Begin of the insertionIfEnd of the insertion Begin of the deletion * Scenarios where dates/duration of a stage/gate is manipulated:

* <br>

* Whenever

* With only duration already set on a stage (or a gate being manipulated which always has a duration of 0)

* WithEnd of the deletion the Begin of the insertionfinishEnd of the insertion Begin of the deletion startEnd of the deletion date Begin of the insertionis updated,End of the insertion Begin of the deletion being set byEnd of the deletion the Begin of the insertiondurationEnd of the insertion Begin of the deletion user

* End dateEnd of the deletion is Begin of the insertionincreased/decreased accordingly. BecauseEnd of the insertion Begin of the deletion set:

* provided start date + (duration - 1)

* Start date is set onEnd of the deletion a Begin of the deletion successor (if it exists)

* For a stage: provided startEnd of the deletion date Begin of the insertionrange pickerEnd of the insertion Begin of the deletion + (duration - 1) + 1

* For a gate: provided start date + (duration - 1)

* End dateEnd of the deletion is Begin of the insertionemployed,End of the insertion Begin of the deletion set on a predecessor (if it exists)

* For a stage: provided start date - 1

* For a gate: provided start date - 1

* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn

* WithEnd of the deletion the Begin of the insertionuser&#39;s intend is clear. The succeeding stages/gates are updating accordingly without changing their duration.

IfEnd of the insertion Begin of the deletion end date being set byEnd of the deletion the Begin of the insertiondurationEnd of the insertion Begin of the deletion user

* Start dateEnd of the deletion is Begin of the insertionincreased/decreased, the finishEnd of the insertion Begin of the deletion set:

* provided endEnd of the deletion date Begin of the deletion - (duration - 1)

* Start dateEnd of the deletion is Begin of the insertionupdated accordingly. Then,End of the insertion Begin of the deletion set on a successor (if it exists)

* For a stage: provided end date + 1

* For a gate: provided end date

* End date is set on a predecessor (if it exists)

* For a stage: provided end date - (duration - 1) - 1

* For a gate: provided end date - (duration - 1) - 1

* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn

* With only start date already set on a stage

* WithEnd of the deletion the Begin of the insertionsucceeding stages/gates are movedEnd of the insertion Begin of the deletion end date being setEnd of the deletion by the Begin of the insertionsame amount without changing their duration.

End of the insertion Begin of the deletion user

* Duration is set:

* Provided end date - start date + 1

* Start date is set on a successor (if it exists)

* End of the deletion For Begin of the insertiongatesEnd of the insertion Begin of the deletion a stage: provided end date + 1

* For a gate: provided end date

* Both, potential successor as well as potential predecessor continue to be scheduledEnd of the deletion and Begin of the deletion schedule in turn

* <br>

* <br>

* <br>

* With dates and duration set on predecessor and successor

* WithEnd of the deletion the Begin of the insertionproject start/finish date,End of the insertion Begin of the deletion predecessor being moved

* intoEnd of the deletion the Begin of the insertionrescheduling of the predecessors/successors happens accordingly.

#### IfEnd of the insertion Begin of the deletion future or past

* withEnd of the deletion a Begin of the insertiondates/duration is removed

If the dates ofEnd of the insertion Begin of the deletion stage followingEnd of the deletion a stage Begin of the deletion

* Expected result: The succeeding stage&#39;s end dateEnd of the deletion is Begin of the insertionremoved,End of the insertion Begin of the deletion onEnd of the deletion the Begin of the insertionduration is removed. IfEnd of the insertion Begin of the deletion next day relative toEnd of the deletion the Begin of the insertiondurationEnd of the insertion Begin of the deletion preceding stage&#39;s end date.

* With a gate following a stage

* Expected result: The succeeding gate&#39;s dateEnd of the deletion is Begin of the insertionremoved,End of the insertion Begin of the deletion onEnd of the deletion the Begin of the insertiondates are removed. Then,End of the insertion Begin of the deletion same day asEnd of the deletion the Begin of the insertionsucceeding andEnd of the insertion preceding Begin of the insertionstages also might loose their dates and duration. A gate encountered like this, will always return itsEnd of the insertion Begin of the deletion stage&#39;s endEnd of the deletion date. Begin of the insertionA precedingEnd of the insertion Begin of the deletion

* With aEnd of the deletion stage Begin of the insertionwill loose its end date and duration. AEnd of the insertion Begin of the deletion following a gate

* Expected result: TheEnd of the deletion succeeding Begin of the insertionstage will lose itsEnd of the insertion Begin of the deletion stage&#39;sEnd of the deletion start date Begin of the insertionand duration.

(\[open\]End of the insertion Begin of the deletion is on the next day as the preceding gate&#39;s date.

* With a gate following a gate

* Expected result: The succeeding gate&#39;s date is on theEnd of the deletion same Begin of the deletion dayEnd of the deletion as Begin of the insertionfor when receiving dates butEnd of the insertion Begin of the deletion the preceding gate&#39;s date.

* With the successor being moved

* into the future.

* Expected result: A gap is added between predecessor and successor. The predecessor isEnd of the deletion not Begin of the insertionhaving enough data to reschedule, itEnd of the insertion Begin of the deletion moved.

* into the past.

* ThereEnd of the deletion is Begin of the insertionunclear whetherEnd of the insertion Begin of the deletion no gap.

* Expected result: The successor cannot be moved as that would conflict withEnd of the deletion the Begin of the insertionstage should also loose its other date in the backend or wether to still keep. In either case itEnd of the insertion Begin of the deletion predecessor. An errorEnd of the deletion is Begin of the insertiontoEnd of the insertion Begin of the deletion displayed.

* There is a gap.

* Expected result: The successor canEnd of the deletion be Begin of the insertiondisplayed grayed out inEnd of the insertion Begin of the deletion moved as long asEnd of the deletion the Begin of the insertionfrontend)

End of the insertion Begin of the deletion change is smaller than the gap.End of the deletion The Begin of the insertionremoval willEnd of the insertion Begin of the deletion gap gets eaten up.

* With dates only on the predecessor. Successor doesEnd of the deletion not Begin of the insertioncontinue onEnd of the insertion Begin of the deletion 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

* End of the deletion after Begin of the deletion the predecessor&#39;s dates

* Expected result: The successor receives those dates. There may beEnd of the deletion a Begin of the insertionstageEnd of the insertion Begin of the deletion gap between the predecessor and the successor. The predecessorEnd of the deletion is Begin of the insertionmet.

#### If a stage/gateEnd of the insertion Begin of the deletion unchanged.

* before/overlapping the predecessor&#39;s dates

* \[open\] Expected result: An errorEnd of the deletion is Begin of the insertiondeactivated

If a gateEnd of the insertion Begin of the deletion displayed. The successor&#39;s dates cannot be saved. The predecessorEnd of the deletion is Begin of the insertiondeactivated, no rescheduling needs to take place.End of the insertion Begin of the deletion unchanged.

<br>

Note from Attila:End of the deletion The Begin of the insertiongate will loose its date.

IfEnd of the insertion Begin of the deletion current implementation allows overlap betweenEnd of the deletion a stage Begin of the insertionis deactivated, its start/finish date are removedEnd of the insertion Begin of the deletion and a gate,End of the deletion but Begin of the insertionits durationEnd of the insertion Begin of the deletion 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 successorEnd of the deletion is Begin of the insertionkept.End of the insertion Begin of the deletion moved.End of the deletion The Begin of the insertionsucceeding stage/gate and its successors are movedEnd of the insertion Begin of the deletion predecessor does not receive any dates.

* End of the deletion into the past Begin of the insertionso that no lag betweenEnd of the insertion Begin of the deletion

* Expected result: The successor can be moved. The predecessor does not receive any dates.

* WithEnd of the deletion the Begin of the insertiondisabled stage&#39;sEnd of the insertion predecessor Begin of the insertionandEnd of the insertion Begin of the deletion getting dates set

* With the dates being before the successor&#39;s dates

* \[open\] Expected result: TheEnd of the deletion successor Begin of the insertionremains.

(\[open\] This currently contradictsEnd of the insertion Begin of the deletion keeps its dates.

* WithEnd of the deletion the Begin of the insertionfigma files)

#### If a stage/gate is activated

If a gate is activatedEnd of the insertion Begin of the deletion dates overlapping/afterEnd of the deletion the Begin of the insertiongate receives the predecessors finish date (stage) or date (gate) for its own date.

If a stageEnd of the insertion Begin of the deletion successor&#39;s dates

* Expected result: The successorEnd of the deletion is Begin of the insertionactivated, it receivesEnd of the insertion Begin of the deletion moved to start onEnd of the deletion the day after the Begin of the insertionpredecessors finish date (stage) or date (gate) asEnd of the insertion Begin of the deletion predecessor&#39;s new end date.

* Without any dates set

* Predecessor getsEnd of the deletion its Begin of the insertionstart date. Its finish isEnd of the insertion Begin of the deletion dates set.

* \[open\] Expected result: The predecessor getsEnd of the deletion the Begin of the insertionstart date plusEnd of the insertion Begin of the deletion dates set. The successor does not receive any dates automatically.

* Successor gets its dates set.

* Expected result: The successor getsEnd of the deletion the Begin of the insertionpotentially stored duration. If no duration is stored,End of the insertion Begin of the deletion dates set. The dates of the predecessor are not set automatically.

* Scenarios whereEnd of the deletion a Begin of the insertionduration of 1End of the insertion Begin of the deletion LifeCycleStep with an existing valueEnd of the deletion is Begin of the insertionassumed soEnd of the insertion Begin of the deletion being enabled:

* whenEnd of the deletion the Begin of the insertionfinish date isEnd of the insertion Begin of the deletion value conflicts with the predecessor&#39;s date:

* \[open question\] Should we call rescheduling, or let the user solve the validation errorEnd of the deletion on the Begin of the insertionsame date ofEnd of the insertion Begin of the deletion dialog?

* whenEnd of the deletion the Begin of the insertionstart date. Succeeding stages and gates are rescheduled intoEnd of the insertion Begin of the deletion value conflicts withEnd of the deletion the Begin of the insertionfuture accordingly.

(\[open\] This currently contradictsEnd of the insertion Begin of the deletion successor&#39;s date:

* \[open question\] Should we call rescheduling, or letEnd of the deletion the Begin of the insertionfigma files)

#### Other scenarios

End of the insertion Begin of the deletion user solve the validation error on the dialog?

End of the deletion * 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:

* Begin of the insertionCurrently, no automatic rescheduling happens. ButEnd of the insertion Begin of the deletion RescheduleEnd of the deletion the Begin of the insertionfirst timeEnd of the insertion Begin of the deletion projects whereEnd of the deletion the Begin of the deletion 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 theEnd of the deletion user Begin of the insertiontouchesEnd of the insertion Begin of the deletion to solveEnd of the deletion the Begin of the insertionlifecycle,End of the insertion Begin of the deletion validation error? (We agreed to letEnd of the deletion the Begin of the insertionout of order lifecycle steps are reordered keeping their duration unchanged.End of the insertion Begin of the deletion 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)End of the deletion

* 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.


**Out of scope**

* Non working days are for now available start/end dates and count towards the duration.

* This is subject to change but doing so would increase the complexity.

* Adding a lag value other than 0 will be implemented later. Begin of the deletion

* <br>End of the deletion