Content
View differences
Updated by Parimal Satyal about 3 years ago
_**As** a project member,_
_**I want to** know when start/finish dates of work packages are changed by related/child work packages (and not directly on the work package itself)_
_**so that** I'm never confused as to what or who triggered the date change._
### Acceptance criteria
When dates of a work package are changed as a result of date changes Steps to child work packages or related work packages: reproduce
* Journal date changes triggered by external work packages.
* Display this change in the activity tab in this format:
> * **Dates changed** by predecessor [_#14525_](https://community.openproject.org/work_packages/14525)
> * **Start date** changed to 12/04/2023
> * **Finish date** changed to 19/04/2023
> * **Duration** changed from 5 days to _6 days_
* Use one of these strings, depending on the change:
* For date changes caused by relations:
* "**Dates changed** by predecessor #{id}"
* "**Dates changed** by follower #{id}"
* For date changes caused by children:
* "**Dates changed** by child #{id}"
* Continue attributing the date change on this (the affected) work package to the user who made the change in the related/child work package.
* In the aggregation of updates, only name the responsible work package for the last update.
* _Note from WL: If multiple work packages caused a change, informing only about the last one is sufficient as this explains the update. The knowledge about earlier updates are gone anyways during the ggregation period (suggestion from_ [_this comment_](https://community.openproject.org/projects/openproject/work_packages/46312#activity-11)_)._
### Open questions
* Are there any other attributes that can be affected by relations, apart from dates and duration?
* From Wieland's [previous comments](https://community.openproject.org/projects/openproject/work_packages/46312/activity#activity-11):
* Do we need to specify the type of relation ("changed by follower", "changed by predecessor", "changed by child" ...) or simply say something like "changed by related #{id}".
* Note from WL: _"That would still explain the origin for an update but will remove a lot of extra information that would need to get stored and distinguished on subsequent updates."_
* Is it acceptable that the existence of a work package IDs get "leaked" to users who might otherwise not have access to it?
* _Note from WL: This is already currently the case for the percentage done field._
###
### Archived bug report
> **Steps to reproduce**
>
> 1. Login to QA Edge and create 2 WPs in predecessor-follower relation
> 2. Set dates on both making sure that the follower starts the day after the predecessor finishes
> 3. Change the finish date of the predecessor by choosing any date in the future so that the start date of the follower gets automatically updated
>
> 4. Go to the follower WP Activity tab and check comments for the latest changes
>
> **What
### What is the buggy behavior?**
>
> behavior?
* There is a comment that dates are changed, however we don't know that it was automatically changed (rescheduled) because just judging from the comment, we might think that the user changed them.
>
> **<img
<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/51963/content">**
>
> **What src="/api/v3/attachments/51963/content">
### What is the expected behavior?**
>
> behavior?
1. It would be good to have an automatic message similar to "Updated automatically by changing values within child work package" comment whenever dates on the follower change automatically so that we know how and why dates were changed.
>
> **Important note**
>
> changed.
### Important note
There is already a bug ticket for missing automatic comment on parent-child work packages: <mention class="mention" data-id="46312" data-type="work_package" data-text="#46312">#46312</mention>
>
> data-text="#46312">#46312</mention>
**OpenProject version**
>
>
12.5.0
_**I want to** know when start/finish dates of work packages are changed by related/child work packages (and not directly on the work package itself)_
_**so that** I'm never confused as to what or who triggered the date change._
### Acceptance criteria
When dates of a work package are changed as a result of date changes
* Journal date changes triggered by external work packages.
* Display this change in the activity tab in this format:
> * **Dates changed** by predecessor [_#14525_](https://community.openproject.org/work_packages/14525)
> * **Start date** changed to 12/04/2023
> * **Finish date** changed to 19/04/2023
> * **Duration** changed from 5 days to _6 days_
* Use one of these strings, depending on the change:
* For date changes caused by relations:
* "**Dates changed** by predecessor #{id}"
* "**Dates changed** by follower #{id}"
* For date changes caused by children:
* "**Dates changed** by child #{id}"
* Continue attributing the date change on this (the affected) work package to the user who made the change in the related/child work package.
* In the aggregation of updates, only name the responsible work package for the last update.
* _Note from WL: If multiple work packages caused a change, informing only about the last one is sufficient as this explains the update. The knowledge about earlier updates are gone anyways during the ggregation period (suggestion from_ [_this comment_](https://community.openproject.org/projects/openproject/work_packages/46312#activity-11)_)._
### Open questions
* Are there any other attributes that can be affected by relations, apart from dates and duration?
* From Wieland's [previous comments](https://community.openproject.org/projects/openproject/work_packages/46312/activity#activity-11):
* Do we need to specify the type of relation ("changed by follower", "changed by predecessor", "changed by child" ...) or simply say something like "changed by related #{id}".
* Note from WL: _"That would still explain the origin for an update but will remove a lot of extra information that would need to get stored and distinguished on subsequent updates."_
* Is it acceptable that the existence of a work package IDs get "leaked" to users who might otherwise not have access to it?
* _Note from WL: This is already currently the case for the percentage done field._
###
### Archived bug report
> **Steps to reproduce**
>
> 1. Login to QA Edge and create 2 WPs in predecessor-follower relation
> 2. Set dates on both making sure that the follower starts the day after the predecessor finishes
> 3. Change the finish date of the predecessor by choosing any date in the future so that the start date of the follower gets automatically updated
>
>
>
> **What
### What
>
>
>
> **<img
<img
>
> **What
### What
>
>
>
> **Important note**
>
>
### Important note
>
>
>
>