Redmine

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.

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.

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.

I can confirm that this is a problem with 1.0.0 (RC) (2010-07-18). Anybody know when it might be fixed?

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.

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

I found these other related issues:

• Feature #4590: Precede-Follow relation moves backward
• Defect #5398: Can not reschedule the start date of following issues at once

JiuG Neiva wrote:

I found these other related issues:

• Feature #4590: Precede-Follow relation moves backward
• Defect #5398: Can not reschedule the start date of following issues at once

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

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.

Still have the problem as described in #4590 with version 1.2.1 stable.

still occurs on version 2.x

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?

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.

This was the intended behaviour, but #4590 is now implemented for 2.2.0. Following issues are now rescheduled in both directions.