Content
View differences
Updated by Parimal Satyal almost 4 years ago
**As** an OpenProject user
**I want** to calculate the work package start and end dates based on the duration
**so** that I only have to set the duration.
# **Acceptance criteria:**
The duration feature affects a range of views and modules:
### Work package attributes and date picker
* In the date picker modal there is a text field `duration`.
* When the user enters a duration and duration, the dates are derived (given at least one of the dates date field is set, the other is derived: set).
* The contrary is also true: when a user enters dates, the duration is derived.
* More precise scenarios for what is derived/calculated as a result of what input (in which order). order), are [presented below](https://community.openproject.org/#scenarios).
* The duration represents the amount of days between the start and the finish date (inclusive):
* Monday to Tuesday: 2 days
* Monday to Monday (same day): 1 day
* Duration is always in full days (never floating point values).
* Once configuring non-working days is implemented (<mention class="mention" data-id="18416" data-type="work_package" data-text="#18416">#18416</mention>), these non-working days are _skipped_ _over_ and do not count towards the total duration:
* Friday to Monday: 2 days _(Saturday and Sunday are skipped over)_
* The user is able to override configured non-working days per work package by choosing to include them via package; this means non-working can be optionally included, in which case they are _not_ skipped and count towards the date-picker (more date and duration count. More details on [this feature in the [feature describing the datepicker](https://community.openproject.org/work_packages/41341): <mention datepicker](https://community.openproject.org/work_packages/41341) (<mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>).
* Changes to As a general rule, no system changes of non-working days via instance settings should never change dates. the start and finish dates of any work package.
* If non-working days are added or removed for the instance by an administration, this will _never_ change the start or finish dates of work packages.
* Instead, the _duration_ field is updated when work packages span added or removed non-working days.
* The journal will be displayed to the user for _affected_ work packages only, attributed to the author (admin who make the change), author, like so:
* For changes to the work week: "Jean Cérien has configured Friday as a non-working day. Duration changed from 5 to 4 days." **(**<mention class="mention" data-id="87" data-type="user" data-text="@Jens Ulferts"><strong>@Jens Ulferts</strong></mention>**, we need to take these new journal changes into consideration.)**
* For changes to individual non-working days: "Jean Cérien has configured 10.10.2022 as a non-working day. Duration changed from 3 to 2 days."
* The only exception is if a start/end date of a work package falls on a date that is now configured to be a non-working day; in this case, the duration is still unchanged and the dates are preserved.
* However, the "Include non-working days" option is now enabled to allow the dates to be preserved.
* In all cases, the duration is consistent with the start and the finish date. Updating dates will update duration, and updating duration will update dates.
* It will not possible, for example, to specify a duration of 8 days for a task that starts and finishes the same week.
* For a work package that has a start date, a finish date and thus thus, also a duration, removing one of the dates (start or finish) will also remove the duration; the duration will now be 1 day **(\[open\] Or should duration be empty in this case?)** zero.
* Of course, clicking on a second date (or manually adding a second date) will add a new duration and the duration will be changed and all three fields will now be complete.
* This also means that it is not possible to conserve duration by deleting the dates, since deleting one date will also delete duration. To remove start and finish dates from a work package that already has these fields but keep the duration, the duration will then have to be re-entered after removing the dates. (Since duration always conforms with selected dates and dates + duration are interdependent).
* It is not possible to remove duration from a field that has start and end dates. (For example, if the user clears the text field manually, the value will automatically be re-entered on blur based on start and finish dates).
* The duration as well as start and due dates can not be configured via the form configuration. They are always present at the same place within the work package show page and form.
* This will be later updated with <mention class="mention" data-id="40539" data-type="work_package" data-text="#40539">#40539</mention>.
* New work packages have an empty (not set) default duration
* **\[open\] Again, or should default be 1 day?**
* Unless unless the user has enabled the setting to give new work packages the current day (today) as the start date. In this case, this setting is respected.
* Certain date/duration information is derived (third value when two fields are filled).
* Setting start _and_ end dates automatically sets duration.
* Setting only one of the dates does not automatically set duration (unable to derive).
* Setting only one of the dates plus the duration sets the other date (derived).
* It is possible to have _no attributes_, _only one attribute_ or all three. It is not possible to have just two (since the third will be derived from the other two).
* Concretely, these are **possible**:
* No start date, no finish date; no duration -- is possible.
* No start date; no finish dates; duration set -- is possible
* Start date specified; no finish date; no duration -- is possible.
* No start date; finish date specified; no duration -- is possible
* But these are **not possible**:
* Start date specified; no finish date; duration specified -- is _not possible_. (End date is derived)
* No start date; finish date specified; duration specified -- is _not possible_. (Start date is derived)
* Start date specified; no finish date; duration specified -- is _not possible_. (End date is derived)
* No start date; finish date specified; duration specified -- is _not possible_. (Start date is derived).
* Milestone-typed work packages don't have a duration field (see <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention> for details). field.
* In 12.2 and 12.3, they will internally have a value of 1 day and behave as it does today.
* This means that when a milestone has a follows/preceeds relation with a work package, there will still be a minimum gap of a day between them.
* GANNT chart: a milestone is still displayed as a diamond.
* Team planner: a milestone spans 1 day.
* Uses the "simple" date picker, with just one date field and no duration.
* **\[closed\]** Should it "take" a day, when scheduling? Currently it does, but perhaps it's wrong?
* Yes, it will "take" a day when scheduling. This is not ideal but to change it requires a more extensive evaluation of consequences of a potential (almost certainly) breaking change. We can consider this for the next major release, but 12.x will keep the current behaviour.
* Concerning relations: The user has to to be informed when:
* Dates are automatically derived from relations (notably from parents or children),
* The user is always given a way to view relations, via an information banner (see <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>).
* these automatically derived dates can not be modified, _unless_ manual scheduling is enabled, and thus relations are ignored.
* Schedules can be updated by moving certain work packages, within these limits:
* The parent's start and finish dates are determined by those of children (it will always that the start date of the earlist child and the finish date of the latest one).
* ~~A work package A that has a~~ _~~preceeds~~_ ~~relationship with another one B, is limited to start/finish dates earlier than those of B.~~
* A preceeding work package (in a preceeds/following relationship) can be moved. If it is moved beyond the start date of any following work packages, those will update such that they start at least one day _after._
* A work package Y that has a _follows_ relationship with another one X, is limited to start/finish dates later than those of X.
* It can, however, be freely moved into the future.
* If a "following" or "preceeding" relationship is added to a work package without dates or duration, this will get a start date that is a date after the preceeding work package. This will not automatically give it a duration.
* When adding If a "following" relationship leads is added to a derivation work package _with_ existig start and finish dates:
* If the start date of a this "following" work package is earlier than the finish date (start or finish), of the "preeceding" work package, it will be changed to one day after the finish date of this preceeding work package. The end date will be derived to maintain the duration (respecting non-working days).
* If the start date of this "following" work package is still not later than the finish date of the "preeceding" work package, it will remain unchanged. The gap can be as big as the user wants, as long as the following work package begins after the preceeding work package ends,
* \[closed\] It is possible to create a "cascading" schedule by creating a set (empty). of work packages with only duration information (no start/finish dates) and a cascading series of "following" relationships.
* Adding a start date to the first work package in this cascade will then automatically add start/finish dates to all following work packages (the first one's finish date will be derived from duration, and each following work package's start date will be set as one day after the finish date of the preceeding one).
* It is also possible to set a start date in the _middle_ of this cascade, to then have start/finish dates for all _following_ work packages.
* Non-working days are respected (i.e, skipped) by default, unless specified otherwise in the date picker by checking the "Include non-working days" checkbox.
### Work package table view
* In the work packages list there is a column "duration". When clicking on this, the date modal with the date picker is opened, with the focus on the duration field.
* Ideally the value is displayed with the value followed by the unit as a full word "days" (and "jours", "Tage" and so forth) handling pluralisation correctly. If we don't already have a system in place to do that, we can fall back on "d" (and "j", and "t" and so forth)
* Filtering by duration is possible
* Sorting by duration is possible
### GANTT chart
* For work packages without start/finish dates but _with_ duration, the width of a "strip" representing such a work package on hover on a GANTT view has a width that is relative to its total duration (on drag over GANTT).
* "Relative" because width depends on the zoom level of the GANTT chart.
* On click, end date is calculated based on the the start date selected.
* If the duration is very long one (finish date is outside of current view), the user will first have to click to commit, and then zoom out or scroll to view the finish date.
* If the user modifies a work package via the drag handles on the left/right edges of the strips the in Gantt chart, both the start/finish date as well as the duration are altered in lockstep, based on which side is dragged.
* If non-working are included for that work package (via the date-picker), they will need to be taken into account in the GANTT too (for example, the work package should span the weekend if the weekend is included).
### Team planner
* For work packages without start/finish dates but _with_ duration:
* they are not visible on the Team planner calendar until a date is specified (they can of course be accessed using the "Add Existing" function)
* the width of a card that is dragged onto the team planner (from the left-hand "Add Existing" panel, for example) is relative to the total duration of that work package (within the limits of the viewport, of course). package.
* Once dragged, the start date is set and therefore the finish date is also derived.
* If the user modifies a work package via the drag handles on the left/right edges of the cards on the Team planner, both the start/finish date as well as the duration are altered in lockstep. lockstep.s
# Open Questions Answered
* Visuals for the rework and repositioning of the dates & duration fields in a work package are handled separately (<mention class="mention" data-id="40539" data-type="work_package" data-text="#40539">#40539</mention>)
* Inheritance of the duration between a work package and its children
* If all children have start/end dates, the parent's start and end dates dates (and thus also duration) are derived.
* The dates and duration are automatically derived and not user-configurable.
* It is possible to enable manual scheduling, in which case the user has full agency to change the dates as they please; however, the dates of children will no longer affect the parent, and will no longer be constrainted by them.
* If children only have duration, then the parent cannot have neither start/end dates nor duration.
* The duration of a parent is _à minima_ a sum of the duration of the children, but this cannot be inferred, since there can be a gap between children. Therefore, this information will be left blank.
* Since a parent spans the duration of all child work packages, this implies that if even one child has the option to include non-working days checked, the parent will also technically include non-working days. This does not have any functional value, since the dates are simply the start and end dates of the first and last children, but it does affect how duration is calculated. (And in the default automatic scheduling of the parent, none of these dates or duration are user-modifiable).
* How will the duration be reflected in the activity, assuming that duration should be part of the activity? (<mention class="mention" data-id="42924" data-type="work_package" data-text="#42924">#42924</mention> )
* If dates are changed (which affects duration), then that will considered a date and duration change: changed.
* Ideally, the duration is also specified in brackets. Eg. "Finish date changed to 2022.10.13. Duration changed to 2022.10.13 (duration is now 3 days." days)".
* If This is the same if duration is changed (and this affects finish date), then it's the same thing. display will be the same.
* For work packages with only duration, then the duration will be an independent journal entry: additional activity that is displayed, if the duration is altered.
* eg. "Duration changed to 3 days".
# Visuals
#### **The new date picker drop modal**
<img class="op-uc-image op-uc-image_inline" style="width:535px;" src="/api/v3/attachments/36033/content"> <figure class="image op-uc-figure" style="width:75%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/31062/content"></div></figure>
Additional visuals for the date picker are in the related work package describing the date picker <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>.
#### Duration column in a work package table view
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29244/content"></div></figure>
#### The date picker drop modal in the work package table view (duration)
Note that the "duration" field is focused when opening the drop modal by clicking on a duration value.
<figure class="image op-uc-figure" style="width:75%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29243/content"></div></figure>
#### The duration column can also be used to adjust the GANTT chart
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29242/content"></div></figure>
# Seed Data
**Static queries in section "Default data":**
* Gantt chart: Add duration column after column finish date:
**Queries in section favorite views**
* Project plan (Query ID 1): Add duration column after column finish date
* Project plan (Query ID 14): Add duration column after column finish date
# Full screen view
* Currently the status selection is below the subject at the same position for all work package types.
* We also move the dates and the curation to this area (visuals tbd).
* For milestones there is no duration by definition.
# Out-of-Scope
* Consider weekends and holidays (for this ticket, will normally already have been dealt with by <mention class="mention" data-id="18416" data-type="work_package" data-text="#18416">#18416</mention>)
* Summing duration _(need clarification)_
* Grouping by durations _(need clarification)_
**I want** to calculate the work package start and end dates based on the duration
**so** that I only have to set the duration.
# **Acceptance criteria:**
The duration feature affects a range of views and modules:
### Work package attributes and date picker
* In the date picker modal there is a text field `duration`.
* When the user enters a duration and
* The contrary is also true: when a user enters dates, the duration is derived.
* More precise scenarios for what is derived/calculated as a result of what input (in which order).
* The duration represents the amount of days between the start and the finish date (inclusive):
* Monday to Tuesday: 2 days
* Monday to Monday (same day): 1 day
* Duration is always in full days (never floating point values).
* Once configuring non-working days is implemented (<mention class="mention" data-id="18416" data-type="work_package" data-text="#18416">#18416</mention>), these non-working days are _skipped_ _over_ and do not count towards the total duration:
* Friday to Monday: 2 days _(Saturday and Sunday are skipped over)_
* The user is able to override configured non-working days per work package by choosing to include them via
* Changes to
*
* In all cases, the duration is consistent with the start and the finish date. Updating dates will update duration, and updating duration will update dates.
* It will not possible, for example, to specify a duration of 8 days for a task that starts and finishes the same week.
* For a work package that has a start date, a finish date and thus
* Of course, clicking on a second date (or manually adding a second date) will add a new duration and the duration will be changed and all three fields will now be complete.
* This also means that it is not possible to conserve duration by deleting the dates, since deleting one date will also delete duration. To remove start and finish dates from a work package that already has these fields but keep the duration, the duration will then have to be re-entered after removing the dates. (Since duration always conforms with selected dates and dates + duration are interdependent).
* It is not possible to remove duration from a field that has start and end dates. (For example, if the user clears the text field manually, the value will automatically be re-entered on blur based on start and finish dates).
* The duration as well as start and due dates can not be configured via the form configuration. They are always present at the same place within the work package show page and form.
* This will be later updated with <mention class="mention" data-id="40539" data-type="work_package" data-text="#40539">#40539</mention>.
* New work packages have an empty (not set) default duration
* **\[open\] Again, or should default be 1 day?**
* Unless
* Certain date/duration information is derived (third value when two fields are filled).
* Setting start _and_ end dates automatically sets duration.
* Setting only one of the dates does not automatically set duration (unable to derive).
* Setting only one of the dates plus the duration sets the other date (derived).
* It is possible to have _no attributes_, _only one attribute_ or all three. It is not possible to have just two (since the third will be derived from the other two).
* Concretely, these are **possible**:
* No start date, no finish date; no duration -- is possible.
* No start date; no finish dates; duration set -- is possible
* Start date specified; no finish date; no duration -- is possible.
* No start date; finish date specified; no duration -- is possible
* But these are **not possible**:
* Start date specified; no finish date; duration specified -- is _not possible_. (End date is derived)
* No start date; finish date specified; duration specified -- is _not possible_. (Start date is derived)
* Start date specified; no finish date; duration specified -- is _not possible_. (End date is derived)
* No start date; finish date specified; duration specified -- is _not possible_. (Start date is derived).
* Milestone-typed work packages don't have a duration field (see <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention> for details).
* In 12.2 and 12.3, they will internally have a value of 1 day and behave as it does today.
* This means that when a milestone has a follows/preceeds relation with a work package, there will still be a minimum gap of a day between them.
* GANNT chart: a milestone is still displayed as a diamond.
* Team planner: a milestone spans 1 day.
* Uses the "simple" date picker, with just one date field and no duration.
* **\[closed\]** Should it "take" a day, when scheduling? Currently it does, but perhaps it's wrong?
* Yes, it will "take" a day when scheduling. This is not ideal but to change it requires a more extensive evaluation of consequences of a potential (almost certainly) breaking change. We can consider this for the next major release, but 12.x will keep the current behaviour.
* Concerning relations:
*
* The user is always given a way to view relations, via an information banner (see <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>).
* these automatically derived dates can not be modified, _unless_ manual scheduling is enabled, and thus relations are ignored.
* Schedules can be updated by moving certain work packages, within these limits:
* The parent's start and finish dates are determined by those of children (it will always that the start date of the earlist child and the finish date of the latest one).
* ~~A work package A that has a~~ _~~preceeds~~_ ~~relationship with another one B, is limited to start/finish dates earlier than those of B.~~
* A preceeding work package (in a preceeds/following relationship) can be moved.
* A work package Y that has
* It can, however, be freely moved into the future.
* If a
* When adding
* If the start date
* If the start date of this "following" work package
* \[closed\] It is possible to create a "cascading" schedule by creating a
* Adding a start date to the first work package in this cascade will then automatically add start/finish dates to all following work packages (the first one's finish date will be derived from duration, and each following work package's start date will be set as one day after the finish date of the preceeding one).
* It is also possible to set a start date in the _middle_ of this cascade, to then have start/finish dates for all _following_ work packages.
* Non-working days are respected (i.e, skipped) by default, unless specified otherwise in the date picker by checking the "Include non-working days" checkbox.
### Work package table view
* In the work packages list there is a column "duration". When clicking on this, the date modal with the date picker is opened, with the focus on the duration field.
* Ideally the value is displayed with the value followed by the unit as a full word "days" (and "jours", "Tage" and so forth) handling pluralisation correctly. If we don't already have a system in place to do that, we can fall back on "d" (and "j", and "t" and so forth)
* Filtering by duration is possible
* Sorting by duration is possible
### GANTT chart
* For work packages without start/finish dates but _with_ duration, the width of a "strip" representing such a work package on hover on a GANTT view has a width that is relative to its total duration (on drag over GANTT).
* "Relative" because width depends on the zoom level of the GANTT chart.
* On click, end date is calculated based on the the start date selected.
* If the duration is very long one (finish date is outside of current view), the user will first have to click to commit, and then zoom out or scroll to view the finish date.
* If the user modifies a work package via the drag handles on the left/right edges of the strips the in Gantt chart, both the start/finish date as well as the duration are altered in lockstep, based on which side is dragged.
* If non-working are included for that work package (via the date-picker), they will need to be taken into account in the GANTT too (for example, the work package should span the weekend if the weekend is included).
### Team planner
* For work packages without start/finish dates but _with_ duration:
* they are not visible on the Team planner calendar until a date is specified (they can of course be accessed using the "Add Existing" function)
* the width of a card that is dragged onto the team planner (from the left-hand "Add Existing" panel, for example) is relative to the total duration of that work package (within the limits of the viewport, of course).
* Once dragged, the start date is set and therefore the finish date is also derived.
* If the user modifies a work package via the drag handles on the left/right edges of the cards on the Team planner, both the start/finish date as well as the duration are altered in lockstep.
# Open Questions Answered
* Visuals for the rework and repositioning of the dates & duration fields in a work package are handled separately (<mention class="mention" data-id="40539" data-type="work_package" data-text="#40539">#40539</mention>)
* Inheritance of the duration between a work package and its children
* If all children have start/end dates, the parent's start and end dates dates (and thus also duration) are derived.
* The dates and duration are automatically derived and not user-configurable.
* It is possible to enable manual scheduling, in which case the user has full agency to change the dates as they please; however, the dates of children will no longer affect the parent, and will no longer be constrainted by them.
* If children only have duration, then the parent cannot have neither start/end dates nor duration.
* The duration of a parent is _à minima_ a sum of the duration of the children, but this cannot be inferred, since there can be a gap between children. Therefore, this information will be left blank.
* Since a parent spans the duration of all child work packages, this implies that if even one child has the option to include non-working days checked, the parent will also technically include non-working days. This does not have any functional value, since the dates are simply the start and end dates of the first and last children, but it does affect how duration is calculated. (And in the default automatic scheduling of the parent, none of these dates or duration are user-modifiable).
* How will the duration be reflected in the activity, assuming that duration should be part of the activity? (<mention class="mention" data-id="42924" data-type="work_package" data-text="#42924">#42924</mention> )
* If dates are changed (which affects duration), then that will considered a date and duration change:
*
* If
* For work packages with only duration, then the duration will be an independent journal entry:
* eg. "Duration changed to 3 days".
# Visuals
#### **The new date picker drop modal**
<img class="op-uc-image op-uc-image_inline" style="width:535px;" src="/api/v3/attachments/36033/content">
Additional visuals for the date picker are in the related work package describing the date picker <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>.
#### Duration column in a work package table view
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29244/content"></div></figure>
#### The date picker drop modal in the work package table view (duration)
Note that the "duration" field is focused when opening the drop modal by clicking on a duration value.
<figure class="image op-uc-figure" style="width:75%;"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29243/content"></div></figure>
#### The duration column can also be used to adjust the GANTT chart
<figure class="image op-uc-figure"><div class="op-uc-figure--content"><img class="op-uc-image" src="/api/v3/attachments/29242/content"></div></figure>
# Seed Data
**Static queries in section "Default data":**
* Gantt chart: Add duration column after column finish date:
**Queries in section favorite views**
* Project plan (Query ID 1): Add duration column after column finish date
* Project plan (Query ID 14): Add duration column after column finish date
# Full screen view
* Currently the status selection is below the subject at the same position for all work package types.
* We also move the dates and the curation to this area (visuals tbd).
* For milestones there is no duration by definition.
# Out-of-Scope
* Consider weekends and holidays (for this ticket, will normally already have been dealt with by <mention class="mention" data-id="18416" data-type="work_package" data-text="#18416">#18416</mention>)
* Summing duration _(need clarification)_
* Grouping by durations _(need clarification)_