Content
View differences
Updated by Jens Ulferts about 1 year ago
## Phases as work package attribute
**As** a project member
**I want to** assign to and see the assignment of a work package to a phase
**so that** I can better understand the context the work package is in.
Assumes ###58159 is done.
**Acceptance criteria**
* Work packages receive a new attribute: The phase they belong to.
* The name of the attribute is "Project phase".
* A work package can be assigned to a single phase. There is no multi assignment.
* In case no project phase is active in the project, the "Project phase" field is hidden.
* The attribute can be administrated same as every other attribute (e.g. status, assignee, version).
* It can be moved in and out of an attribute group.
* \[open\] Should this be an attribute that is seeded? If so, which group should it be seeded into?
* Existing installations are not migrated to have the attribute activated for their existing types.
* The attribute's value is displayed including the colored type indicator prefix in both the split/full view as well as the table.
* \[Technical detail\] It is probably not possible to display the existence/non existence of a gate for the stage.
* The attribute can be changed via an ng-select.
* \[Technical detail\] Getting the data for displaying the existence/non existence of a gate should be possible here, but it will require coding a variation of the autocompleter.
* The attribute can be added as a column to the work package list.
* The table can be ordered and grouped by that column.
* The order is not by name of the phase but by the order the phase are in.
* The group header has the colored icon prefixed (if possible).
* Within the table column for project phases, the selected phase is displayed and can be edited same as in the split & full screen view: The selected value has a colored icon prefixed same as the possible values in the autocompleter.
* The attribute can be filtered by. There is a single filter called the same as the work package attribute available in both the global work package list as well as in the project work package lists.
* The available operators are 'is (or)', 'is not', 'is empty' and 'is not empty'.
* The values available are:
* in a work package list inside a project: The project phases active in that project
* in the global work package list: All project phases.
* \[open\] should this be limited to only return phases active in any project the user is member in (or public project)
* The filter is not available in the project if there are no active project phases. In the global list, the filter is hidden if there is no project phase configured in the OP instance (all deleted).
* The attribute is journalized. For this, the standard phrases for associated objects (e.g. Assignee and Version) are used.
* In case a phase is inactive in the project, this is displayed after the name of the project phase displayed in the journal, e.g. "Project phase set to Initiating (Inactive)".
* In case the associated phase is later disabled in the project administration, the value is no longer displayed displayed, changes are not shown in the journal and a the work package having the disabled phase associated is are not found via filters (see ###58163).
* The API v3 has a dedicated resource for phases
* GET endpoint for referencing a selected phase
* GET endpoint for selecting all available (active) phases of the project when selecting the value of the attribute.
* The attribute is properly exported on the single and collection PDF export of work packages.
* The attribute can be referenced using the `workPackageValue:[:some_id]:projectPhase` macro.
* The new functionality is hidden behind the feature flag developed as part of ###58159
**Permission considerations**
* The property and all the related functionality is only available if the user has the permission 'view\_project\_phases' in the project the work package is associated to. This extends to i.e.
* Filters
* Displaying the value in the table and on the split/full screen view.
* Activity?
* \[open\] Check if this is possible at all.
**Out of scope**
* Showing changes when activating the work package baseline comparison.
* Indicating the time span the phase spans in the date picker of the work package.
* This would indicate when the work package should be worked on.
* Date alert notification in case a work package is not finished but the phase ends.
* A hard limit regarding the dates or a message displayed if the dates are outside of the phase's date range.
* This would also require rescheduling a work package in case the phase's dates are changed. The complexity of this would be quite high.
* Displaying the phase's time span inside the gantt chart.
* Having the attribute selectable to be displayed left/right/far right in the Gantt-Chart.
**As** a project member
**I want to** assign to and see the assignment of a work package to a phase
**so that** I can better understand the context the work package is in.
Assumes ###58159 is done.
**Acceptance criteria**
* Work packages receive a new attribute: The phase they belong to.
* The name of the attribute is "Project phase".
* A work package can be assigned to a single phase. There is no multi assignment.
* In case no project phase is active in the project, the "Project phase" field is hidden.
* The attribute can be administrated same as every other attribute (e.g. status, assignee, version).
* It can be moved in and out of an attribute group.
* \[open\] Should this be an attribute that is seeded? If so, which group should it be seeded into?
* Existing installations are not migrated to have the attribute activated for their existing types.
* The attribute's value is displayed including the colored type indicator prefix in both the split/full view as well as the table.
*
*
* The table can be ordered and grouped by that column.
* The order is not by name of the phase but by the order the phase are in.
* The group header has the colored icon prefixed (if possible).
* Within the table column for project phases, the selected phase is displayed and can be edited same as in the split & full screen view: The selected value has a colored icon prefixed same as the possible values in the autocompleter.
* The attribute can be filtered by. There is a single filter called the same as the work package attribute available in both the global work package list as well as in the project work package lists.
* The available operators are 'is (or)', 'is not', 'is empty' and 'is not empty'.
* The values available are:
* in a work package list inside a project: The project phases active in that project
* in the global work package list: All project phases.
* \[open\] should this be limited to only return phases active in any project the user is member in (or public project)
* The filter is not available in the project if there are no active project phases. In the global list, the filter is hidden if there is no project phase configured in the OP instance (all deleted).
* The attribute is journalized. For this, the standard phrases for associated objects (e.g. Assignee and Version) are used.
* In case the associated phase is later disabled in the project administration, the value is no longer displayed
* The API v3 has a dedicated resource for phases
* GET endpoint for referencing a selected phase
* GET endpoint for selecting all available (active) phases of the project when selecting the value of the attribute.
* The attribute is properly exported on the single and collection PDF export of work packages.
* The attribute can be referenced using the `workPackageValue:[:some_id]:projectPhase` macro.
* The new functionality is hidden behind the feature flag developed as part of ###58159
**Permission considerations**
* The property and all the related functionality is only available if the user has the permission 'view\_project\_phases' in the project the work package is associated to. This extends to i.e.
* Filters
* Displaying the value in the table and on the split/full screen view.
* Activity?
* \[open\] Check if this is possible at all.
**Out of scope**
* Showing changes when activating the work package baseline comparison.
* Indicating the time span the phase spans in the date picker of the work package.
* This would indicate when the work package should be worked on.
* Date alert notification in case a work package is not finished but the phase ends.
* A hard limit regarding the dates or a message displayed if the dates are outside of the phase's date range.
* This would also require rescheduling a work package in case the phase's dates are changed. The complexity of this would be quite high.
* Displaying the phase's time span inside the gantt chart.
* Having the attribute selectable to be displayed left/right/far right in the Gantt-Chart.