**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\] Begin of the insertionChanges necessary on the front end.End of the insertion Begin of the deletion Are gaps allowed? Answer: Yes.End of the deletion

* Begin of the insertionMoving the lifecycle step modifications from the modal triggered on the overview pageEnd of the insertion Begin of the deletion \[open\] Should we add an explicit lagEnd of the deletion to Begin of the deletion haveEnd of the deletion the Begin of the insertionproject administration.

End of the insertion Begin of the deletion same behaviour as work packages?

End of the deletion * Begin of the insertionRemovingEnd of the insertion Begin of the deletion \[open\] Are allEnd of the deletion the Begin of the insertionmodal.

End of the insertion Begin of the deletion scenarios correct?

End of the deletion * Begin of the insertionAdding a gantt chartEnd of the insertion Begin of the deletion \[open\] Do we wantEnd of the deletion to Begin of the deletion show allEnd of the deletion the Begin of the insertionproject administration.

* Displaying the lifecycle steps within the gantt.

* Allow drag&dropEnd of the insertion Begin of the deletion changesEnd of the deletion in the Begin of the insertiongantt.

* Stages and gates are automatically (re)scheduled toEnd of the insertion Begin of the deletion modal beforeEnd of the deletion the Begin of the insertionextend the information provided by theEnd of the insertion user Begin of the insertionallows for.

End of the insertion Begin of the deletion commits?

End of the deletion * Begin of the insertionAutomatic scheduling happens as soon as two values out of the three involved attributes (start date, end date & duration) are set (analogousEnd of the insertion Begin of the deletion \[open\] Do we wantEnd of the deletion to Begin of the insertionwork 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.

* 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/date) which can continue as long as each successor is completely specified.

* Active stages/gates are considered to be following each other based on the sort order in the administration.End of the insertion Begin of the deletion introduce modification by durations?End of the deletion

* Begin of the insertionIn case a stage/gate is inactive in a project, the next active stage/gate is considered to be the successor. Multiple inactive stages/gatesEnd of the insertion Begin of the deletion If so,End of the deletion can Begin of the insertionbe ignored that way.

* Stages receiveEnd of the insertion a duration Begin of the insertionthe user can manipulate.

* The duration canEnd of the insertion be set independently Begin of the insertionfrom theEnd of the insertion Begin of the deletion (withoutEnd of the deletion start and end Begin of the insertiondate. In other words, stage might have a duration without having a start/endEnd of the insertion date Begin of the insertionset.

* The duration has to be an integer value of at least 1.End of the insertion Begin of the deletion set)?End of the deletion

* Begin of the insertionGates don't have a duration (it can be considered to always be 0)

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

* End of the insertion \[open\] Begin of the insertionAre all the scenarios correct?

* \[open\]End of the insertion 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? Begin of the deletion

* \[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.End of the deletion


Scenarios:

Currently this only describes the backend's behaviour and not what is to happen on the frontend.

Begin of the insertionThe scenarios are currently being rewritten so this is work in progress.

End of the insertion * Scenarios where Begin of the insertiondates/duration ofEnd of the insertion Begin of the deletion there isEnd of the deletion a stage/gate Begin of the insertionis manipulated:End of the insertion Begin of the deletion with a succeeding stage/gate:End of the deletion

* With Begin of the insertiononly durationEnd of the insertion Begin of the deletion datesEnd of the deletion set on Begin of the insertiona stageEnd of the insertion Begin of the deletion predecessor and successorEnd of the deletion

* With the Begin of the insertionstart dateEnd of the insertion Begin of the deletion predecessorEnd of the deletion being Begin of the insertionset by the userEnd of the insertion Begin of the deletion movedEnd of the deletion

* Begin of the insertionEnd date is set:End of the insertion Begin of the deletion into the futureEnd of the deletion

* Begin of the insertionprovided start date + (duration - 1)

End of the insertion Begin of the deletion without any gap between them.

End of the deletion * Begin of the insertionStart dateEnd of the insertion Begin of the deletion Expected result: The succeeding stage/gateEnd of the deletion is Begin of the insertionset on a successor (if it exists)

End of the insertion Begin of the deletion moved by the same number of days (start and end date)

End of the deletion * Begin of the insertionFor a stage: provided start date + (duration - 1) + 1

End of the insertion Begin of the deletion with enough gap to include the moved amount of days.

End of the deletion * Begin of the insertionForEnd of the insertion Begin of the deletion Expected result: The gap is eaten up. The successor is not moved. There is nowEnd of the deletion a Begin of the insertiongate: provided start date + (duration - 1)

End of the insertion Begin of the deletion smaller gap between the two.

End of the deletion * Begin of the insertionEnd dateEnd of the insertion Begin of the deletion ThereEnd of the deletion is Begin of the insertionset onEnd of the insertion a Begin of the insertionpredecessor (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 continueEnd of the insertion Begin of the deletion gap between the two stages/gates but not enoughEnd of the deletion to Begin of the insertionbe scheduled and scheduleEnd of the insertion Begin of the deletion completely takeEnd of the deletion in Begin of the insertionturn

* WithEnd of the insertion the Begin of the insertionend date being set byEnd of the insertion Begin of the deletion changed dates ofEnd of the deletion the Begin of the insertionuser

End of the insertion Begin of the deletion predecessor.

End of the deletion * Begin of the insertionStart dateEnd of the insertion Begin of the deletion Expected result: The gapEnd of the deletion is Begin of the insertionset:

* provided end date - (duration - 1)

* Start dateEnd of the insertion Begin of the deletion eaten up. The successorEnd of the deletion is Begin of the insertionset on a successor (if it exists)

* For a stage: providedEnd of the insertion Begin of the deletion moved by the delta of the changed predecessor'sEnd of the deletion end date Begin of the insertion+ 1

* For a gate: provided end date

* End dateEnd of the insertion Begin of the deletion and the previous gap. ThereEnd of the deletion is Begin of the insertionset on a predecessor (if it exists)

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

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

* Both, potential successor as well as potential predecessor continue to be scheduled and scheduleEnd of the insertion Begin of the deletion no gapEnd of the deletion in Begin of the insertionturn

* <br>

* <br>

* <br>

* With dates and duration set on predecessor and successor

* WithEnd of the insertion the Begin of the insertionpredecessor being moved

End of the insertion Begin of the deletion end.

End of the deletion * into the Begin of the insertionfuture orEnd of the insertion past

* Begin of the insertionwith a stage following a stageEnd of the insertion Begin of the deletion without any gap between them.End of the deletion

* Expected result: The succeeding Begin of the insertionstage&#39;s end dateEnd of the insertion Begin of the deletion stage/gateEnd of the deletion is Begin of the insertiononEnd of the insertion Begin of the deletion moved byEnd of the deletion the Begin of the insertionnext day relative to the preceding stage&#39;sEnd of the insertion Begin of the deletion same number of days (start andEnd of the deletion end Begin of the insertiondate.End of the insertion Begin of the deletion date)End of the deletion

* Begin of the insertionWithEnd of the insertion Begin of the deletion withEnd of the deletion a Begin of the insertiongate following a stageEnd of the insertion Begin of the deletion gap between the two stages/gates.End of the deletion

* Begin of the deletion \[open\]End of the deletion Expected result: The succeeding Begin of the insertiongate&#39;s dateEnd of the insertion Begin of the deletion stage/gateEnd of the deletion is Begin of the insertiononEnd of the insertion Begin of the deletion moved byEnd of the deletion the same Begin of the insertionday as the preceding stage&#39;sEnd of the insertion Begin of the deletion number of days (start andEnd of the deletion end Begin of the insertiondate.

* With a stage following a gate

* Expected result:End of the insertion Begin of the deletion date).End of the deletion The Begin of the insertionsucceeding stage&#39;s start date is onEnd of the insertion Begin of the deletion gap continues to exist withEnd of the deletion the Begin of the insertionnext 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 insertion same Begin of the insertionday as the preceding gate&#39;s date.End of the insertion Begin of the deletion number of days between predecessor and successor.End of the deletion

* 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&#39;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&#39;s dates

* \[open\] Expected result: An error is displayed. The successor&#39;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&#39;s dates

* \[open\] Expected result: The successor keeps its dates.

* With the dates overlapping/after the successor&#39;s dates

* Expected result: The successor is moved to start on the day after the predecessor&#39;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&#39;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&#39;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. Begin of the insertion


**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.End of the insertion