Content
View differences
Updated by Christophe Bliard almost 4 years ago
Copied from <mention class="mention" data-id="31992" data-type="work_package" data-text="#31992">#31992</mention> and <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention> (which are still authoritative, so double check the requirements there)
Checklist:
* [ ] work package edit form endpoint
* [x] Derive start date, finish date, or duration field when the two others are set ([opf/openproject#11177](https://github.com/opf/openproject/pull/11177))
* [x] Derive start date, finish date, or duration field field when only 2 are set and one is unset ([opf/openproject#11177](https://github.com/opf/openproject/pull/11177))
* [x] [ ] Correctly calculate duration based on defined non-working days
* [ ] Have the work package edit form endpoint return an error when trying to set all 3 fields to an invalid state
* [ ] 2 set, one nil ⇒ error
* [ ] 3 set but invalid duration ⇒ error
* [x] Keep duration and change due date or start due date when changing `ignoreNonWorkingDays`
* [ ] Change start date and due date to next working day when switching `ignoreNonWorkingDays` from `true` to `false`
from <mention class="mention" data-id="31992" data-type="work_package" data-text="#31992">#31992</mention>
> * 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).
>
> \[...\]
>
> * 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/precedes relation with a work package, there will still be a minimum gap of a day between them.
>
> \[...\]
>
> * When an administrator changes non-working days via instance admin settings (adds or removes a working day), this will affect dates of scheduled work packages. If non-working days are added or removed for the instance by an admin, the _duration_ is preserved, which might mean the start and finish dates might change.
from <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>
> "Include non-working days" checkbox
>
> * If a work package already has start and end dates (and thus also duration) and the user enables this checkbox, the duration is preserved the dates are updated to include days that were previously skipped (the weekends, primarily).
> * **Example:** A work package with a start date on a Thursday, and with a duration of 4 days, had a finish date of Tuesday (since Saturday and Sunday were skipped). Now, that non-working days are included, the finish date is now Sunday, and the duration remains 4 days.
> * If the user goes back to working days only (from previously included non-working days), the duration is once again maintained, but the finish date is pushed to now skip over the non-working days.
> * **Example:** In the same example as before, the work package now once again starts on a Thursday, finishes on a Tuesday and has a duration of 4 days.
> * **Example 2:** A user changes then the start date such that the work package now starts on normally non-working day (Saturday). The duration remains 4 days, with a finish date of Tuesday. Deactivating this option will now also move the start date to Monday, with a finish date of Thursday (again, to maintain duration).
> * If a work package only has one set of date information (just start date, just end date, or just duration), clicking this button will not affect any of the values until a second piece of information is also input (with one exception).
> * **For example,** for a work package with a start date only (so no duration), clicking this will immediately do nothing. However, if a second date is clicked, the duration calculated will now include non-working days.
> * **Exception:** when the option is enabled, and the one date is on a normally non-working day (Saturday), then disabling this option has to move that date to the first available working day (in the future); in this case, it would be Monday.
The date picker will have start date, finish date, and duration fields. They will be kept in sync by making request to `/api/v3/projects/{id}/work_packages/form` to get information from backend. The backend will derive the missing date or duration field from the two others, and the date picker will use the response to update its UI.
This work package focuses on having the form and update endpoints behaving as described in <mention class="mention" data-id="43539" data-type="work_package" data-text="#43539">#43539</mention> which can be summed up like this:
* 3rd field is filled when the other 2 are known.
* When all fields are filled, the currently modified field is kept, then start date is kept, then finish date is kept.
* Saying it the other way: duration is changed when dates changes, and finish date is changed if duration changes.
* Works also when unsetting a field: unsetting duration will unset finish date (keep start date). Or unsetting start date will unset duration (keep finish date)
With some additional corner case information:
* For milestone type
* duration is always 1 day internally
* if finish date or start date is set to null, the other date is set to null (because duration is always 1 day)
* If start date or end date is a non working day, when switching `ignoreNonWorkingDays` to `false`, then the start date is shifted from non-working day to the next working day, and the finish date derived from new start date and duration. If finish date is the only field set, it shifts from non-working day to the next working day
Relates to <mention class="mention" data-id="42923" data-type="work_package" data-text="#42923">#42923</mention> which implements unsetting a field when another one is unset.
Checklist:
* [ ] work package edit form endpoint
* [x] Derive start date, finish date, or duration field when the two others are set ([opf/openproject#11177](https://github.com/opf/openproject/pull/11177))
* [x] Derive start date, finish date, or duration field field when only 2 are set and one is unset ([opf/openproject#11177](https://github.com/opf/openproject/pull/11177))
* [x]
* [ ] Have the work package edit form endpoint return an error when trying to set all 3 fields to an invalid state
* [ ] 2 set, one nil ⇒ error
* [ ] 3 set but invalid duration ⇒ error
* [x] Keep duration and change due date or start due date when changing `ignoreNonWorkingDays`
* [ ] Change start date and due date to next working day when switching `ignoreNonWorkingDays` from `true` to `false`
from <mention class="mention" data-id="31992" data-type="work_package" data-text="#31992">#31992</mention>
> * 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).
>
> \[...\]
>
> * 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/precedes relation with a work package, there will still be a minimum gap of a day between them.
>
> \[...\]
>
> * When an administrator changes non-working days via instance admin settings (adds or removes a working day), this will affect dates of scheduled work packages. If non-working days are added or removed for the instance by an admin, the _duration_ is preserved, which might mean the start and finish dates might change.
from <mention class="mention" data-id="41341" data-type="work_package" data-text="#41341">#41341</mention>
> "Include non-working days" checkbox
>
> * If a work package already has start and end dates (and thus also duration) and the user enables this checkbox, the duration is preserved the dates are updated to include days that were previously skipped (the weekends, primarily).
> * **Example:** A work package with a start date on a Thursday, and with a duration of 4 days, had a finish date of Tuesday (since Saturday and Sunday were skipped). Now, that non-working days are included, the finish date is now Sunday, and the duration remains 4 days.
> * If the user goes back to working days only (from previously included non-working days), the duration is once again maintained, but the finish date is pushed to now skip over the non-working days.
> * **Example:** In the same example as before, the work package now once again starts on a Thursday, finishes on a Tuesday and has a duration of 4 days.
> * **Example 2:** A user changes then the start date such that the work package now starts on normally non-working day (Saturday). The duration remains 4 days, with a finish date of Tuesday. Deactivating this option will now also move the start date to Monday, with a finish date of Thursday (again, to maintain duration).
> * If a work package only has one set of date information (just start date, just end date, or just duration), clicking this button will not affect any of the values until a second piece of information is also input (with one exception).
> * **For example,** for a work package with a start date only (so no duration), clicking this will immediately do nothing. However, if a second date is clicked, the duration calculated will now include non-working days.
> * **Exception:** when the option is enabled, and the one date is on a normally non-working day (Saturday), then disabling this option has to move that date to the first available working day (in the future); in this case, it would be Monday.
The date picker will have start date, finish date, and duration fields. They will be kept in sync by making request to `/api/v3/projects/{id}/work_packages/form` to get information from backend. The backend will derive the missing date or duration field from the two others, and the date picker will use the response to update its UI.
This work package focuses on having the form and update endpoints behaving as described in <mention class="mention" data-id="43539" data-type="work_package" data-text="#43539">#43539</mention> which can be summed up like this:
* 3rd field is filled when the other 2 are known.
* When all fields are filled, the currently modified field is kept, then start date is kept, then finish date is kept.
* Saying it the other way: duration is changed when dates changes, and finish date is changed if duration changes.
* Works also when unsetting a field: unsetting duration will unset finish date (keep start date). Or unsetting start date will unset duration (keep finish date)
With some additional corner case information:
* For milestone type
* duration is always 1 day internally
* if finish date or start date is set to null, the other date is set to null (because duration is always 1 day)
* If start date or end date is a non working day, when switching `ignoreNonWorkingDays` to `false`, then the start date is shifted from non-working day to the next working day, and the finish date derived from new start date and duration. If finish date is the only field set, it shifts from non-working day to the next working day
Relates to <mention class="mention" data-id="42923" data-type="work_package" data-text="#42923">#42923</mention> which implements unsetting a field when another one is unset.