Content
View differences
Updated by Henriette Darge about 6 years ago
### Acceptance criteria
* The time of For parent work packages is shown with "clamps", displayed children ('clamps'), the time frame the children take up is visualized as a bar below the clamps visualized:
* 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) clamp.
* 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.
* 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.
### 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
* 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.
* 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.
### 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.