Content
View differences
Updated by Jens Ulferts almost 6 years ago
### Acceptance criteria
* The time of parent work packages is shown with "clamps", the time frame the descendants children take up is visualized as a bar below the clamps
* If the children's time frame is completely within the parent's time frame, it is displayed as a gray bar within the clamp (see picture)
* If the children's time frame is partly or completely outside of the parent's time frame, it is displayed as a red bar (partly) outside the clamp.
> Do we want to also signal to the user that the manual scheduling is off in cases where the automatic date would different due to other reasons, e. g. if a precedes relationship would move the work package backwards in time.
* If all Work Packages are scheduled manually, it is possible that the clamp and the bar are completely separated.
### Out of scope
* Only the earliest date and the latest date define the bar symbolizing the child work packages and the bar is solid between those two dates. In other words, there is no representation of the individual child work packages time frames.
### Open
* The acceptance criteria only takes heed of a work package's children. Assumption: We need to take all descendants into account as the children might be scheduled manually as well.
### Implementation notes
* The time frame of the children will need to be provided via the API
* Extend the API to include the children's time frame
* They are to be displayed independently of the visibility of the children to the user. So even if the user is not allowed to see the children, the time frame the children require is displayed.
* It is probably faster to store the children's time frame than to calculate it upon fetching. However, that would require storing the information and keeping it in sync when
* Deleting children
* Moving children
* Adding children
* Modifying children
* Because of the reasons stated above, we should fetch it in one query from the backend as part of the work package eager loading. This also needs to take place when fetching individual work packages.
* The time of parent work packages is shown with "clamps", the time frame the descendants
* If the children's time frame is completely within the parent's time frame, it is displayed as a gray bar within the clamp (see picture)
* If the children's time frame is partly or completely outside of the parent's time frame, it is displayed as a red bar (partly) outside the clamp.
* If all Work Packages are scheduled manually, it is possible that the clamp and the bar are completely separated.
### Out of scope
* Only the earliest date and the latest date define the bar symbolizing the child work packages and the bar is solid between those two dates. In other words, there is no representation of the individual child work packages time frames.
### Open
* The acceptance criteria only takes heed of a work package's children. Assumption: We need to take all descendants into account as the children might be scheduled manually as well.
### Implementation notes
* The time frame of the children will need to be provided via the API
* Extend the API to include the children's time frame
* They are to be displayed independently of the visibility of the children to the user. So even if the user is not allowed to see the children, the time frame the children require is displayed.
* It is probably faster to store the children's time frame than to calculate it upon fetching. However, that would require storing the information and keeping it in sync when
* Deleting children
* Moving children
* Adding children
* Modifying children
* Because of the reasons stated above, we should fetch it in one query from the backend as part of the work package eager loading. This also needs to take place when fetching individual work packages.