Content
View differences
Updated by Parimal Satyal over 3 years ago
### Note
This feature was originally a bug report (archived below for context) and affects how work packages with a precedes/follows react when one of them is moved either to the past or to the future.
### Acceptance criteria
The basic acceptance criterion can be stated simply as:
* When moving preceeding work packages in a precedes/follows relationship, the distance is never conserved.
* That is, the dates of the following work packagae are only affected (pushed into the future) when distance < 0, as is the case today.
More specificially, in a scenario where work package B follows work package A with a distance of n days (that is, there are n days between when A finishes and B starts):
* If A is moved to the past, the dates of B are conserved as is.
* If A is moved to the future,
* If the new finish date of A is before the start date of B, the dates of B are unaffected.
* If the new finish date of A is after the start date of B (the "follows" relationship is violated), then B is moved such that its start date is 1 day after the finish date of A (distance == 0, current behaviour).
* If B is moved to the future, this is possible and dates of A are conserved as is (assuming no additional constraints).
* If B is moved to the past,
* If the new start date of B is after the finish date of A, this is possible and dates of A are conserved as is (assuming no additional constraints).
* If the new start date of B is before the finish date of A, this is **not possible** and an error is displayed (current behaviour).
### The original bug report (archived)
#### Note
1. Not sure if this is bug report or a feature request. We might come to the conclusion to move this to another version.
2. The word distance is used to describe the number of days between two related packages (implicit). It is not the (explicit) lag between two work packages. There is currently no UI representation for the lag attribute. The lag can only be CRUD using the API.
3. In the API and the database lag is currently named "Delay": ##44054
#### ### Steps to reproduce
1. Go to the _Work packages_ module and activate Gantt view.
2. Create two work packages (wp1 and wp2).
3. Give wp1 and wp2 the same start and finish dates, with a duration of 2 days.
4. Add a relation so that wp2 "follows" wp1.
* Wp2's start and finish dates will change as a result, such that wp2 starts the next available day after wp1's finish date.
5. Move wp2 into the future so that there are 4 days in between wp1 and wp2 (distance = 3 days).
6. **Adjustment 1:** Move wp1 two days into the future. Note that this does not push wp2 by two days; instead, the **distance** _**is reduced**_ from 3 days to 1 day (two days in between).
7. **Adjustment 2:** Now move wp1 two days into the past. Note that in this case, this pulls wp2 ahead by two days; a **distance** _**of 1 day is conserved**_ (2 days in between).
8. **Adjustment 3:** Now move wp1 such that it's start date is past the start date of wp. Note that wp2 is pushed so that it starts the first available day after wp1 ends, **disctance is set to zero.**
#### ### What is the buggy behavior?
* When the distance is set by moving wp2 into the future on the Gantt chart, the behaviour is not consistent between when wp1 is moved backwards or fowards in time (between adjustment 1 and 2).
* Moving wp1 into the past changes start/finish dates of wp2 and conserves distance.
* Moving wp1 into the future preserves start/finish dates of wp2 and reduces distance.
* Note that in the case of adjustment 3 (wp1 moved beyond wp2), the work packages are rescheduled as expected (wp2 starts 1 day after wp1, lag = 0).
#### ### What is the expected behavior?
* The distance is not preserved when moving wp 1 into the past.
* WP2 is only rescheduled if the change of WP1 would create a negative distance (distance <0).
#### ## Next step - out of scope
#### * We implement a user interface to CRUD the existing lag attribute.
#### ### Screenshots and other files
This screencap illustrates steps 5–8 of 'Steps to reproduce':
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/38374/content">
#### ### Environment information
**OpenProject installation type**
All
**OpenProject version**
12.2
This feature was originally a bug report (archived below for context) and affects how work packages with a precedes/follows react when one of them is moved either to the past or to the future.
### Acceptance criteria
The basic acceptance criterion can be stated simply as:
* When moving preceeding work packages in a precedes/follows relationship, the distance is never conserved.
* That is, the dates of the following work packagae are only affected (pushed into the future) when distance < 0, as is the case today.
More specificially, in a scenario where work package B follows work package A with a distance of n days (that is, there are n days between when A finishes and B starts):
* If A is moved to the past, the dates of B are conserved as is.
* If A is moved to the future,
* If the new finish date of A is before the start date of B, the dates of B are unaffected.
* If the new finish date of A is after the start date of B (the "follows" relationship is violated), then B is moved such that its start date is 1 day after the finish date of A (distance == 0, current behaviour).
* If B is moved to the future, this is possible and dates of A are conserved as is (assuming no additional constraints).
* If B is moved to the past,
* If the new start date of B is after the finish date of A, this is possible and dates of A are conserved as is (assuming no additional constraints).
* If the new start date of B is before the finish date of A, this is **not possible** and an error is displayed (current behaviour).
### The original bug report (archived)
#### Note
1. Not sure if this is bug report or a feature request. We might come to the conclusion to move this to another version.
2. The word distance is used to describe the number of days between two related packages (implicit). It is not the (explicit) lag between two work packages. There is currently no UI representation for the lag attribute. The lag can only be CRUD using the API.
3. In the API and the database lag is currently named "Delay": ##44054
####
1. Go to the _Work packages_ module and activate Gantt view.
2. Create two work packages (wp1 and wp2).
3. Give wp1 and wp2 the same start and finish dates, with a duration of 2 days.
4. Add a relation so that wp2 "follows" wp1.
* Wp2's start and finish dates will change as a result, such that wp2 starts the next available day after wp1's finish date.
5. Move wp2 into the future so that there are 4 days in between wp1 and wp2 (distance = 3 days).
6. **Adjustment 1:** Move wp1 two days into the future. Note that this does not push wp2 by two days; instead, the **distance** _**is reduced**_ from 3 days to 1 day (two days in between).
7. **Adjustment 2:** Now move wp1 two days into the past. Note that in this case, this pulls wp2 ahead by two days; a **distance** _**of 1 day is conserved**_ (2 days in between).
8. **Adjustment 3:** Now move wp1 such that it's start date is past the start date of wp. Note that wp2 is pushed so that it starts the first available day after wp1 ends, **disctance is set to zero.**
####
* When the distance is set by moving wp2 into the future on the Gantt chart, the behaviour is not consistent between when wp1 is moved backwards or fowards in time (between adjustment 1 and 2).
* Moving wp1 into the past changes start/finish dates of wp2 and conserves distance.
* Moving wp1 into the future preserves start/finish dates of wp2 and reduces distance.
* Note that in the case of adjustment 3 (wp1 moved beyond wp2), the work packages are rescheduled as expected (wp2 starts 1 day after wp1, lag = 0).
####
* The distance is not preserved when moving wp 1 into the past.
* WP2 is only rescheduled if the change of WP1 would create a negative distance (distance <0).
####
####
####
This screencap illustrates steps 5–8 of 'Steps to reproduce':
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/38374/content">
####
**OpenProject installation type**
All
**OpenProject version**
12.2