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). below)
* Seeded stages: Initiating: #F7983A, #F7983A (24 days), Planning: #F05823, #F05823 (48 days), Executing: #EC038A, #EC038A (96 days), Closing: #B1D13A (24 days)
* The duration in the brackets is for the initially seeded project
* The colors are newly created if they do not exist (in Administration -> Colors).
* The seeded stages and gates are internationalized (during seeding process, can not be changed later). later)
* 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). This includes anonymous and non-members.
* 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.
* 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.
* A gate's date can not be the same as another gate's date.
* There is no automatic rescheduling when changing dates of predecessors.
* Stages/gates of the child project limited are not limited by the dates in the parent project.
* Include stages/gate instances in the two seeded projects.
* The dates set in the demo project are relative to the seeding date. The project start date is seven days after the seeding date.
* The seeded dates need to be updated.
* \[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/stages of a project gates are journalized.
* \[open\] What messages are written when initially setting/updating/unsetting a gate/stage's date(s).
**Out of scope**
* Duration
* Lag
* Inheritance to sub projects
* Seeding of stages/gates for demo projects (##58303)
**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,
* The
* The
* The seeded stages and gates are internationalized (during seeding process, can not be changed later).
* 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). This includes anonymous and non-members.
* 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.
* 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.
* A gate's date can not be the same as another gate's date.
* There is no automatic rescheduling when changing dates of predecessors.
* Stages/gates of the child project limited are not limited by the dates in the parent project.
*
* The dates set in the demo project are relative to the seeding date. The project start date is seven days after the seeding date.
* The seeded dates need to be updated.
* \[open\] Could be done in a separate feature.
*
* Changes to the gates/stages of a project
* \[open\] What messages are written when initially setting/updating/unsetting a gate/stage's date(s).
* Duration
* Lag
* Inheritance to sub projects
* Seeding of stages/gates for demo projects (##58303)