There are several elements that needs a milestone duration to works properly
- Burn-up chart
- Burn-down chart
- Milestone dates display
- Computation of "is it hot or not"
At the moment, the values are computed with "Start date" + "duration" with some magical to exclude saturday and sunday. It should be possible to define the timeperiod with a combination of "Start date" + "End date" as an alternative (keeping the Sat/Sun magical exclusion).
Timeframe semantic
Introduce a "Timeframe" semantic in tracker configuration (target: milestones trackers). A Timeframe can be defined with either
- A start date and duration
- A start date and a end date
In semantic configuration, tracker admins can select which computation mode they prefer and the target fields (like other semantics).
Impacts of this new semantic
- Fields that are being used by the semantic can no longer be deleted until the semantic is deleted
- Burndown and Burnup charts depends on this semantic
- Configuration error messages should be change to refer to Timeframe semantic instead of individual fields
- Timeframe Semantic cannot be deleted as long as there is
- A burndown
- Or a burnup
- Those dependencies should be clearly stated in Timeframe semantic and in each element.
- On Velocity semantic
- There is no dependencies between semantics (technically they can live independently)
- However, the display of the graph should check correct usage of Timeframe semantic:
- When no sub-milestones have a Timeframe semantic defined, no graph is displayed but an error message to inform that a Timeframe is mandatory to get the graph.
- When at least one sub-milsetone doesn't have a Timeframe, the graph is displayed in best-effort and an error message is displayed to inform about missing configuration of Timeframe semantic.
- There is a "ForgeUpgrade" bucket to import hardcoded configuration to semantic for existing trackers
- All trackers were there are duration & start_date used fields will get the new semantic
When the configuration of the Timeframe semantic is changed (either computation mode or fields)
- there is no re-computation of existing graphs.
- a new entry is added in project history to record the changes (will ease support)
Tracker common work with new semantic:
- should be inherited a tracker creation.
- imported/exported by XML
- added to REST tracker resources
The documentation is updated with new semantic and more details about semantic dependencies (should be done with "Done" semantic as well).
Usage of Timeframe
The new timeframe semantic is used in
- Burndown boundaries definition
- Burnup boundaries definition
- Velocity chart tooltip
- Display of milestone dates in Planning
- Display of milestone dates in Cardwall + time progress bar
- AgileDashboard service page to identify what's hot and what's next
If there is no timeframe semantic defined
- It's not possible to have burndow or burnup field
- It's not possible to define the Velocity semantic
- Dates and time progress bar are not displayed in Planning and Cardwall views
- There is no longer "What's next" on AgileDashboard, there is only "What's done" and "What's hot".
Usage in artifact view
An helper is added on "duration" or "end_date" field (depending of the config) to display the reverse information automatically computed.
- When 'duration' is used, the corresponding end date is displayed as an hint (like for computed value)
- When 'end_date' is used, the corresponding duration is displayed (the same way).
This info is displayed
- In Artifact view
- In Artifact "angular" modale (Planning view & co)
To be checked technically
- There are SQL queries with direct usage of duration that are likely to be false ATM (as duration can be computed). This needs to be checked
- All direct usage of start_date / duration must be replaced by an abstracted "timeperiod" representation.