Content
View differences
Updated by Aleix Suau almost 6 years ago
\* Depends on [https://github.com/opf/openproject/pull/8547](https://github.com/opf/openproject/pull/8547) to be merged to get the proper data
### TODO
* [ ] Show work package's children duration bar on Gantt charts (grey bar inside the clamp)
* [ ] The date range of the bar comes under the properties derivedStartDate and derivedDueDate. When the WP has children, its subject is set to 'parent'.
* [ ] Show the work package's children duration bar in red when its derivedDueDate is after the work package dueDate.
### QUESTIONS
* In the code, the clamp is only displayed when the parent has visible children on the table (_if_ (_this_.isParentWithVisibleChildren(wp)). Should we only show the children duration bar then?
### NOTES
* checkForSpecialDisplaySituations renders the clamp
### Acceptance criteria
* The time of parent work packages is shown with "clamps", the time frame the descendants 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.
### 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.
### TODO
* [ ] Show work package's children duration bar on Gantt charts (grey bar inside the clamp)
* [ ] The date range of the bar comes under the properties derivedStartDate and derivedDueDate. When the WP has children, its subject is set to 'parent'.
* [ ] Show the work package's children duration bar in red when its derivedDueDate is after the work package dueDate.
### QUESTIONS
* In the code, the clamp is only displayed when the parent has visible children on the table (_if_ (_this_.isParentWithVisibleChildren(wp)). Should we only show the children duration bar then?
### NOTES
* checkForSpecialDisplaySituations renders the clamp
### Acceptance criteria
* The time of parent work packages is shown with "clamps", the time frame the descendants 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.
### 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.