Content
View differences
Updated by Christophe Bliard about 2 years ago
#### Context
Since version 14.0, % Complete is tied to Work and Remaining work. Milestones have always had the ability to have these fields, and thus also have progress. Yet, a Milestone is by definition duration-less and cannot have progress. It is merely meant to be a checkpoint or marker in the timeline.
This work package is to decide how we deal with this in the context of the recent changes to Progress. We can also choose to not address this issue in this work stream and decide to address it separately in a larger feature to intorduce Milestones are a completely separate type of object.
#### **Open points**
Questions to be resolved concerning Milestones (from <mention class="mention" data-id="74738" data-type="user" data-text="@Christophe Bliard">@Christophe Bliard</mention>, copied from #54496):
* How should they be displayed in the work package table view?
_\[Parimal: W/RM/%C values should be empty\]_
* Does a milestone wp with rejected status have the little information icon saying that the values are not included for totals calculations?
_\[Parimal: No, it does not\]_
* should % complete be shown at all when in status-based mode or should it stay unset?
* should totals be computed and shown for milestone types?
* Should the values be removed when changing type from task to milestone?
_\[Parimal: Yes they should be removed; a milestone doesn't have these values so it would be like if the new type did not have the fields to accomodate existing values\]_
* Should we have a migration to remove all values for milestone-types?
_\[Parimal: Logically, yes. But I see the challenges around this\]_
* Should the values be removed when the "is milestone" flag is changed on a work package status?
_\[Parimal: Logically yes. Although I'm not sure why it's necessary to have multiple types defined as milestones; might need historical context to understand this)_
#### Related
###54496
Since version 14.0, % Complete is tied to Work and Remaining work. Milestones have always had the ability to have these fields, and thus also have progress. Yet, a Milestone is by definition duration-less and cannot have progress. It is merely meant to be a checkpoint or marker in the timeline.
This work package is to decide how we deal with this in the context of the recent changes to Progress. We can also choose to not address this issue in this work stream and decide to address it separately in a larger feature to intorduce Milestones are a completely separate type of object.
#### **Open points**
Questions to be resolved concerning Milestones (from <mention class="mention" data-id="74738" data-type="user" data-text="@Christophe Bliard">@Christophe Bliard</mention>, copied from #54496):
* How should they be displayed in the work package table view?
_\[Parimal: W/RM/%C values should be empty\]_
* Does a milestone wp with rejected status have the little information icon saying that the values are not included for totals calculations?
_\[Parimal: No, it does not\]_
* should % complete be shown at all when in status-based mode or should it stay unset?
* should totals be computed and shown for milestone types?
* Should the values be removed when changing type from task to milestone?
_\[Parimal: Yes they should be removed; a milestone doesn't have these values so it would be like if the new type did not have the fields to accomodate existing values\]_
* Should we have a migration to remove all values for milestone-types?
_\[Parimal: Logically, yes. But I see the challenges around this\]_
* Should the values be removed when the "is milestone" flag is changed on a work package status?
_\[Parimal: Logically yes. Although I'm not sure why it's necessary to have multiple types defined as milestones; might need historical context to understand this)_
#### Related
###54496