Content
View differences
Updated by Aleix Suau almost 6 years ago
Work ork packages are always shown as bars.
* The label is always right to the bar.
* If a work package has derived dates from children there are clamps below the bar. Also if the children are not on the same page or filtered out. Or the user does not have the permission to see the children. childre.
*
* The clamp turns red if the derived dates are before/after the manually scheduled dates (shown case). The clambs are black in case the derived dates are "inside" the dates.
* In the automatic scheduling mode there are black clambs below the bar indicating that there are children.
### Out of scope
* show progress indicator inside the bars
* warning signs in the children work package that indicate that it outside the parent's work package.
#
# Old specicifation (changed during implementation)
\* 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
* [x] Show work package's children duration bar on Gantt charts (grey bar inside the clamp)
* [x] The date range of the bar comes under the properties derivedStartDate and derivedDueDate. When the WP has children, its subject is set to 'parent'.
* [x] Show the work package's children duration bar in red when its derivedDueDate is after the work package dueDate.
* [ ] Show the derivedStartDate and derivedDueDate when we hover the children duration bar??
### 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?
* What red should we use for the overflowed bar (text contrast)?
* The grey seems too dark to me
* Should we show the derivedStartDate and derivedDueDate when we hover the children duration bar?
* Should I create tests for this? I can't find any related to the bars
### 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.
* The label is always right to the bar.
* If a work package has derived dates from children there are clamps below the bar. Also if the children are not on the same page or filtered out. Or the user does not have the permission to see the children.
*
*
* In the automatic scheduling mode there are black clambs below the bar indicating that there are children.
* show progress indicator inside the bars
* warning signs in the children work package that indicate that it outside the parent's work package.
#
# Old specicifation (changed during implementation)
\* 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
* [x] Show work package's children duration bar on Gantt charts (grey bar inside the clamp)
* [x] The date range of the bar comes under the properties derivedStartDate and derivedDueDate. When the WP has children, its subject is set to 'parent'.
* [x] Show the work package's children duration bar in red when its derivedDueDate is after the work package dueDate.
* [ ] Show the derivedStartDate and derivedDueDate when we hover the children duration bar??
### 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?
* What red should we use for the overflowed bar (text contrast)?
* The grey seems too dark to me
* Should we show the derivedStartDate and derivedDueDate when we hover the children duration bar?
* Should I create tests for this? I can't find any related to the bars
### 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.