Content
View differences
Updated by Niels Lindenthal 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\] Which stages/gates are seeded? What color are they seeded with? Which order are they to be in.
* \[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 \[open\] What is the name of this permission?
* Pre-seeding: All project \[open\] Which of the preseeded roles get this permission receive the permission? Assumption - Project admin.
* Migrations \[open\] Which of the existing roles receive the permission on existing installations: instances? Assumption - All project roles get having the 'edit project' permission.
* \[open\] Visualization of this permission (since they are empty no data is leaked) area. Assumption - The colors should also be displayed here.
* The area showing the stages/gates in the current project the dates of the stages can be modified.
* Modifying the dates of the stages/gates requires a project permission different from the view permission.
* Name: Edit project stages and gates (includes \[Assumption\] Receiving the edit permission requires to also have the view permission) permission.
* Pre-seeding: The role project admin gets this permissions \[open\] Which of the preseeded roles receive the permission? Assumption - Project admin.
* Migrations \[open\] Which of the existing roles receive the permission on existing installations: instances? Assumption - All project roles that get this permission that have having the permission "edit project". 'edit project' permission.
* 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
* \[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 \[Assumption\] There is no required minimum length for a stage. A stage is one day: This means a stage can start and end on the same date.
* \[Assumption\] There is no maximum length for a stage.
* \[Assumption\] 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 stage's date be the same as another stage's date. Assumption - No, this is not possible.
* \[open\] We might need something like "lag" in the future.
* Include stages/gate instances in the two seeded projects.
* \[open\] The Which dates should be set for the gates in the demo project are relative to the seeding date. The seeding date is seven days after the seeding date. those projects?
* \[open\] Could be done in a separate feature.
* \[Assumption\] 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 behaviour similar to the other copy options.
* Changes \[open\] Should changes to the gates are journalized. be 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\] 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
* Migrations
* \[open\] Visualization of
* The area showing the stages/gates in the current project the dates of the stages can be modified.
* Modifying the dates of the stages/gates requires a project permission different from the view permission.
* Name: Edit project stages and gates (includes
* Pre-seeding: The role project admin gets this permissions
* Migrations
* 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
* \[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.
* Include stages/gate instances in the two seeded projects.
* \[open\] The
* \[open\] Could be done in a separate feature.
*
* Changes