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: Initiation: #F7983A,
* Planning: #F05823,
* Executing: Execution: #EC038A,
* Closing: Closure: #B1D13A
* 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).
* The PMI provided localizations for the seeded stages are to be used in all the languages ([**https://www.pmi.org/standards/pmbok**](https://www.pmi.org/standards/pmbok)**)**.
* \[open\] What about the 5th stage defined by PMI - "Monitoring/Controlling"
* \[open\] PMI does not define gates.
* 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 and gates have an two input field to modify their date (range). 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.
* \[open\] Should a project start date be added (needed for ASAP scheduling potentially and if we want to allow people working only with the start date)
* 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 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:
* Planning: #F05823,
* Executing:
* Closing:
* 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).
* The PMI provided localizations for the seeded stages are to be used in all the languages ([**https://www.pmi.org/standards/pmbok**](https://www.pmi.org/standards/pmbok)**)**.
* \[open\] What about the 5th stage defined by PMI - "Monitoring/Controlling"
* \[open\] PMI does not define gates.
* 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 and gates have an
* 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.
* \[open\] Should a project start date be added (needed for ASAP scheduling potentially and if we want to allow people working only with the start date)
* Changes to the gates/stages of a project 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)