Content
View differences
Updated by Jens Ulferts over 1 year ago
**As** a project admin
**I want to** organize the project into dedicated stages
**so that** it is easier to communicate about the stage the project is in and what that means for the progress.
_Note: This is but the first in a number of features which will greatly increase the versatility of stages_
**Acceptance criteria**
* Create a feature flag for the feature hiding all traces of it.
* Seed a fixed set of stage and gate types (for both existing and new instances of OpenProject)
* Those stage and gate types are similar to work package types. They define which stages/gates exist in a project. Each project will then receive instances of those types (see below)
* Seeded stages: Initiating: #F7983A (24 days), Planning: #F05823 (48 days), Executing: #EC038A (96 days), Closing: #B1D13A (24 days)
* \[open\] The duration in the brackets - are those default durations a project should receive or is it the duration the stages/gates should receive in the seeded project?
* \[open\] Should those colors be created in case they do not exist (any more since they were deleted)? Assumption - yes.
* \[open\] Are they internationalized?
* The project overview page has an area which displays the dates configured for each stage/gate in the current project.
* Viewing the stages/gates requires a project permission.
* Name: View project stages and gates
* Pre-seeding: All project roles get this permission
* Migrations on existing installations: All project roles get this permission (since they are empty no data is leaked)
* \[open\] It might still be prudent to limit it to roles having been granted a certain permission. E.g. "View project attributes". Should anonymous and non member receive the permission as well?
* The area showing the stages/gates in the current project's overview page allows the user to modify the dates of each stage/gate.
* Modifying the dates of the stages/gates requires a project permission different from the view permission.
* Name: Edit project stages and gates (~~includes~~ requires view permission)
* Pre-seeding: The role project admin gets this permissions.
* Migrations on existing installations: All project roles that get this permission that have the permission "edit project".
* Stages have two input fields for dates (start/end) while stages have one field.
* \[open\] It might be helpful to define a duration similar to work packages. This facilitates planning and rescheduling. Assumption - Only makes sense in case stages/gates are scheduled automatically. Might be done in a later feature.
* \[open\] It might also be that both have one field and that for stages, a range is defined.
* The user is supported when modifying the dates by the OpenProject date picker.
* The start date of a stage has to be before the end date.
* The minimum length for a stage is one day: This means a stage can start and end on the same date.
* There is no maximum length for a stage.
* Stages cannot have overlapping dates. Gates can overlap the start/end date of a gate. But only exactly the start/end date. The date of a gate cannot be between a stage's dates.
* \[open\] Can a gate's date be the same as another gate's date. Assumption - No, this is not possible.
* \[open\] We might need something like "lag" in the future. Might be added in a later feature.
* \[open\] In case a stage/gate's dates are added/modified and now overlap another stage/gate. Are those conflicting dates rescheduled? Automatically or after confirmation?
* \[open\] In case the project has a parent project - are the dates of the stages/gates of the child project limited by the dates in the parent project?
* Include stages/gate instances in the two seeded projects.
* \[open\] The dates set in the demo project are relative to the seeding date. The seeding date is seven days after the seeding date.
* \[open\] Could be done in a separate feature.
* If a project is copied, the dates for stages/gates are copied as well. There is a setting added when copying to disable this behavior similar to the other copy options.
* Changes to the gates are journalized.
**I want to** organize the project into dedicated stages
**so that** it is easier to communicate about the stage the project is in and what that means for the progress.
_Note: This is but the first in a number of features which will greatly increase the versatility of stages_
**Acceptance criteria**
* Create a feature flag for the feature hiding all traces of it.
* Seed a fixed set of stage and gate types (for both existing and new instances of OpenProject)
* Those stage and gate types are similar to work package types. They define which stages/gates exist in a project. Each project will then receive instances of those types (see below)
* Seeded stages: Initiating: #F7983A (24 days), Planning: #F05823 (48 days), Executing: #EC038A (96 days), Closing: #B1D13A (24 days)
* \[open\] The duration in the brackets - are those default durations a project should receive or is it the duration the stages/gates should receive in the seeded project?
* \[open\] Should those colors be created in case they do not exist (any more since they were deleted)? Assumption - yes.
* \[open\] Are they internationalized?
* The project overview page has an area which displays the dates configured for each stage/gate in the current project.
* Viewing the stages/gates requires a project permission.
* Name: View project stages and gates
* Pre-seeding: All project roles get this permission
* Migrations on existing installations: All project roles get this permission (since they are empty no data is leaked)
* \[open\] It might still be prudent to limit it to roles having been granted a certain permission. E.g. "View project attributes". Should anonymous and non member receive the permission as well?
* The area showing the stages/gates in the current project's overview page allows the user to modify the dates of each stage/gate.
* Modifying the dates of the stages/gates requires a project permission different from the view permission.
* Name: Edit project stages and gates (~~includes~~ requires view permission)
* Pre-seeding: The role project admin gets this permissions.
* Migrations on existing installations: All project roles that get this permission that have the permission "edit project".
* Stages have two input fields for dates (start/end) while stages have one field.
* \[open\] It might be helpful to define a duration similar to work packages. This facilitates planning and rescheduling. Assumption - Only makes sense in case stages/gates are scheduled automatically. Might be done in a later feature.
* \[open\] It might also be that both have one field and that for stages, a range is defined.
* The user is supported when modifying the dates by the OpenProject date picker.
* The start date of a stage has to be before the end date.
* The minimum length for a stage is one day: This means a stage can start and end on the same date.
* There is no maximum length for a stage.
* Stages cannot have overlapping dates. Gates can overlap the start/end date of a gate. But only exactly the start/end date. The date of a gate cannot be between a stage's dates.
* \[open\] Can a gate's date be the same as another gate's date. Assumption - No, this is not possible.
* \[open\] We might need something like "lag" in the future. Might be added in a later feature.
* \[open\] In case a stage/gate's dates are added/modified and now overlap another stage/gate. Are those conflicting dates rescheduled? Automatically or after confirmation?
* \[open\] In case the project has a parent project - are the dates of the stages/gates of the child project limited by the dates in the parent project?
* \[open\] The dates set in the demo project are relative to the seeding date. The seeding date is seven days after the seeding date.
* \[open\] Could be done in a separate feature.
* If a project is copied, the dates for stages/gates are copied as well. There is a setting added when copying to disable this behavior similar to the other copy options.
* Changes to the gates are journalized.