**As** a user
**I want to** have a consistent and understandable inheritance of dates (start/finish) up and down the work package ancestor chain 
**so that** I know what is going to happen when I alter the work package hierarchy (e.g. add a child/parent)

**Acceptance criteria**

* _Setting a date on the child of an already existing parent-child hierarchy_: Inheritance of dates up the ancestor chain (from child to parent) should always only be for the date that is set.
* If neither the parent nor the child has any dates set nor duration set:
* Setting a start date on a child will mean that that parent will inherit _only_ the start date from the child's start date. Duration and finish date of both the parent as well as the child remains unset.
* Analogue behaviour for the finish date.
* Begin of the insertion_**\[open\]**End of the insertion Begin of the deletion **\[open\]**End of the deletion In case the parent has other children (which would also have no dates), will those also receive the date to be their start/finish Begin of the insertiondate?_
* _**\[proposition\]** No, I don't think those children should receive any dates. Children should be allowed to have no dates despite the parent having them (from other children). Essentially, the children who_ do _have dates define the limits for the parent, but those who don't don't simply don't affect those limits._End of the insertion Begin of the deletion date? End of the deletion
* If both parent and child have one date set but no duration:
* Setting the other date on the child will inherit that date up to the parent. Both parent and child have their duration calculated at this point. The values of the duration might differ between parent and child since the parent might have additional children.
* Unsetting the date will lead to the parent also having its date unset. But if the parent has another child with a date, that date will now be used for the parent as Begin of the insertionwell.End of the insertion Begin of the deletion well. End of the deletion
* **\[open\]** In case the parent has other children (which cannot have the changed date but might have the other date set), will those also receive the date to be their start/finish date?
* Begin of the insertion_**\[openEnd of the insertion Begin of the deletion **\[openEnd of the deletion - contradiction\]** In case the parent has other children and the finish date of the child is set. That other child has a start date after the altered child's start date. If the set finish date is before the other child's start date, start and finish date of the parent will be before the other child's start Begin of the insertiondate._
* _**\[answer\]** We need to discuss this in person, I think._End of the insertion Begin of the deletion date.  End of the deletion
* If the parent has a date set but the child does not. The parent would have to have a different child with a date:
* When setting the date of the child for which the parent already has a value. If the value of the child is before (in case of the start date) or after (in case of the finish date) the parent's value, the child's value overwrites the parent's.
* When setting the date of the child for which the parent doesn't have a value. The child's value is inherited to the parent. The parent has its duration Begin of the insertioncalculated.End of the insertion Begin of the deletion calculated. End of the deletion
* Begin of the insertion_**\[openEnd of the insertion Begin of the deletion **\[openEnd of the deletion - contradiction\]** if the value present on the parent is a start date. Setting the finish date of the child to be before the parent's start date, would lead to the parent having a finish date before its start date. Possible solution: Whenever a date of a child is set, that date is not only propagated up to the parent, but from there also down again to all children not having a value for that Begin of the insertiondate._
* _**\[answer\]** We need to discuss this in person, too._End of the insertion Begin of the deletion date.End of the deletion
* Both parent and child have both dates set:
* When setting a date on the child, that date is propagated up to the parent if it is the earliest (start date)/latest (finish date) of all the Begin of the insertionchildren.End of the insertion Begin of the deletion children. End of the deletion
* **\[open - contradiction\]** if the new value of the child's start date is after the finish date of another child, that other child's finish date would end up not being in the interval between the parent's start and finish date. Begin of the insertion
* _**\[answer\]** Same, let's talk about this in person._End of the insertion Begin of the deletion   End of the deletion
* _Creating a new child to a parent_: Inheritance of dates (finish/start) down the ancestor chain (from parent to child) should always only be for the dates that are set. Inheritance in this case can be displaying the value as the default value in a work package form (e.g. full/split screen) or setting the value directly (e.g. inline create within the work package table).
* When the parent has start _and_ finish dates:
* A new child (regardless of whether it is the first or a subsequent one created via any means) inherits both of the dates (and naturally also the duration).
* When the parent only has one date (start _or_ finish):
* A new child (regardless of whether it is the first or a subsequent one created via any means) inherits _only_ this date; the other date and duration remain unchanged.
* _Assigning a parent to an existing work package_: If an existing work package is turned into a child, the parent will receive only the date or dates (start/finish) that are set on the new child.
* It inherits the start date of the earliest child and the finish date of the latest child.
* If no child has a start date, then the parent will have no start date (inheriting the finish date of the latest child).
* Begin of the insertion_**\[open\]**End of the insertion Begin of the deletion **\[open\]**End of the deletion if the parent has a start date (because it wasn't a parent before), will the child receive that start date value? Assumed: Begin of the insertionyes_
* _**\[answer\]** Yes, but let's talk._End of the insertion Begin of the deletion yesEnd of the deletion
* If no child has a finish date, then the parent will have no finish date (inheriting the start date of the earliest child).
* Begin of the insertion_**\[open\]**End of the insertion Begin of the deletion **\[open\]**End of the deletion if the parent has a finish date (because it wasn't a parent before), will the child receive that finish date value? Assumed: Begin of the insertionyes_
* _**\[answer\]** Yes, but let's talk._End of the insertion Begin of the deletion yesEnd of the deletion
* _Setting a date on the parent of an already existing parent-child hierarchy_: The dates of parent work packages are read only. No change is possible.
* **\[open\]** it might be desirable to change that so that setting the value on a parent would lead to all children receiving that value for their Begin of the insertionown.
* _**\[answer\]** Hmm, what is the use-case here? Let's discuss._End of the insertion Begin of the deletion own. End of the deletion
* When milestones become a child, their unique date will be considered start and finish, and it will behave the same as a one-day work package (with the same start and finish dates).

#### _Current behaviour_

* Creating the first child from within the relations tab:
* If the parent has a start date and no date is provided for the child by the user: The child's start date is set to the parent's start date. The parent's finish date is set to the start date of the child (which is the same as the parent's start date) and the duration is set to 1.
* Creating the second, third, ... child from within the relation tab:
* If the parent has a start date and no date is provided for the child by the user: The child's start date is not set. No change is done on the parent's dates.
* Assigning a parent to an already existing child (e.g. via "Set parent" on the full/split screen or by indenting on the Gantt chart)
* The dates of the parent are overwritten. This includes parent dates being deleted in case the child does not have dates.