Defect #5803
closedPrecedes/Follows Relationships Broke
0%
Description
The latest stable release (0.9.5) 'precedes' and 'follows' relationships no longer effect 'Start' and 'Due date's for issues. For example if I change the 'Due date' for 'Task 1.1' which 'precedes' 'Task 1.2', the 'Start' for Task 1.2 should shift accordingly. It no longer does this.
I checked out the 0.9.0 release and those dependencies work as advertised.
Felix Schäfer confirmed this on r3813 as a regression of Feature #279 but asked that I file a Defect.
Perhaps this is related to the sub-issue logic?
Redmine is proving very useful and we are eagerly awaiting the 1.0.0 release candidate on July 3, 2010. I'm hoping this defect can be resolved before that release, because it is a really superb feature in 0.9.0.
- MySQL 5.0.90-community-nt
- Ruby 1.8.7 (2008-08-11 patchlevel 72)
- Rails 2.3.5
- 0.9.5 but also r3813
Files
Related issues
Updated by Yuki Kita about 14 years ago
- File issue.rb.diff issue.rb.diff added
- Assignee deleted (
Jean-Philippe Lang)
Confirmed.
Here is the patch.
The defect is due to the timing of the saving a issue.
Updated by Howard Mall about 14 years ago
Looking at the code, it does not appear to recurse through the 'follows' relationships. For example, we have three issues (Task 1.1, Task 1.2, and Task 1.3) that all follow each other sequentially. Task 1.1 changes its end date. Task 1.2 shifts, but Task 1.3 stays the same.
Updated by Howard Mall about 14 years ago
Looking at the code, it does not appear to recurse through the 'follows' relationships. For example, we have three issues (Task 1.1, Task 1.2, and Task 1.3) that all follow each other sequentially. Task 1.1 changes its end date. Task 1.2 shifts, but Task 1.3 stays the same.
Updated by Howard Mall about 14 years ago
I'm pretty certain of my fix, but I'm still trying to figure out how to make a proper diff file to attach. However, I basically (in app/model/issue.rb) put the :reschedule_following_issues
to occur after_save
and added a call to issue_to.reschedule_following issues
to app/models/issue_relation.rb in the set_issue_to_dates
function. This required that I also make reschedule_following_issues
a public function.
Updated by John Davis about 14 years ago
I can confirm that this is a problem with 1.0.0 (RC) (2010-07-18). Anybody know when it might be fixed?
Updated by Jean-Baptiste Barth about 14 years ago
When it has tests : we don't want it to be broken again in a next release. I may have a look at it if I have the time.
Updated by Jean-Philippe Lang almost 14 years ago
- Status changed from New to Resolved
- Target version set to 1.0.3
- Resolution set to Fixed
Fix and test committed in r4263.
Updated by Eric Davis almost 14 years ago
- Status changed from Resolved to Closed
Merged into 1.0-stable for release in 1.0.3
Updated by JiuG Neiva over 13 years ago
- File Redmine_issue_5803.pdf Redmine_issue_5803.pdf added
Jean-Philippe Lang wrote:
Fix and test committed in r4263.
The relationship is still broken, at lest in version 1.1
It works fine when you change the due date of the preceding task to a later date, but does not work when changed to a previous date.
Please take a look at the attached pdf for more details.
Thanks!
Updated by JiuG Neiva over 13 years ago
JiuG Neiva wrote:
Jean-Philippe Lang wrote:
Fix and test committed in r4263.
The relationship is still broken, at lest in version 1.1
It works fine when you change the due date of the preceding task to a later date, but does not work when changed to a previous date.
Please take a look at the attached pdf for more details.
Thanks!
I can confirm that in version 1.1.1 the problem is still present
Thanks
Updated by JiuG Neiva over 13 years ago
Updated by JiuG Neiva over 13 years ago
JiuG Neiva wrote:
I found these other related issues:
Finally, I found that tengel liu is right in #4590.
The problem, at least in version 1.1 and 1.1.1 is at line 498
Original: if start_date.nil? || start_date < date
Should be: if start_date.nil? || start_date != date
Would be nice to include this in future releases.
Thank you
Updated by Fernando Hartmann over 13 years ago
It's happening in my installation too !
I have a lot of issues whit relationships and is almost impossible to me to correct the dates by hand !
Please correct this problem as fast as you can !
Thanks for the great job.
Updated by Aurélien Appéré almost 13 years ago
Still have the problem as described in #4590 with version 1.2.1 stable.
Updated by Daniel Felix over 11 years ago
evandro bubiak wrote:
still occurs on version 2.x
I can confirm this with the current trunk (r10864).
JiuG Neiva wrote:
It works fine when you change the due date of the preceding task to a later date, but does not work when changed to a previous date.
This still seems to apply. Changes which sets the due date to an earlier date are ignored, only changes which postpone the due date apply on the process chain.
Well maybe this would work as aspected, if you won't prefer the following tickets. But if you want to prefer all following tickets as configured, all other posts must follow the new duedate.
Maybe this could be made by some option "reorganize following..." or something like that?
Updated by Sebastian Hucke over 11 years ago
I can confirm that behavior for our productive redmine system (version 2.0.3).
I think that this is an intended feature. The buffer is implemented like it should be: as a minimum amount of time between two tickets.
jp jp: Am i right? In this case, I would open a feature request for the solution proposed by Daniel Felix. Hopefully, rescheduling will be much better with version 2.2.0, but still not perfect without an option to reschedule automatically to both earlier and later dates.
Daniel Lopez Felix: +1 for your reorganization option.
Updated by Jean-Philippe Lang over 11 years ago
This was the intended behaviour, but #4590 is now implemented for 2.2.0. Following issues are now rescheduled in both directions.