Defect #5803

Precedes/Follows Relationships Broke

Added by Howard Mall over 7 years ago. Updated almost 5 years ago.

Status:ClosedStart date:2010-07-01
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:1.0.3
Resolution:Fixed Affected version:

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

issue.rb.diff Magnifier (1.11 KB) Yuki Kita, 2010-07-05 11:33

Redmine_issue_5803.pdf (206 KB) JiuG Neiva, 2011-02-07 19:59


Related issues

Related to Redmine - Feature #4590: Precede-Follow relation should move following issues when... Closed 2010-01-15
Related to Redmine - Defect #5398: Can not reschedule the start date of following issues at ... New 2010-04-29

Associated revisions

Revision 4263
Added by Jean-Philippe Lang about 7 years ago

Fixed: precedes/follows relations no longer update start/due dates (#5803).

History

#1 Updated by Howard Mall over 7 years ago

  • Assignee set to Jean-Philippe Lang

#2 Updated by Yuki Kita over 7 years ago

Confirmed.
Here is the patch.
The defect is due to the timing of the saving a issue.

#3 Updated by Howard Mall over 7 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.

#4 Updated by Howard Mall over 7 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.

#5 Updated by Howard Mall over 7 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.

#6 Updated by John Davis over 7 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?

#7 Updated by Jean-Baptiste Barth over 7 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.

#8 Updated by Jean-Philippe Lang about 7 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.

#9 Updated by Eric Davis about 7 years ago

  • Status changed from Resolved to Closed

Merged into 1.0-stable for release in 1.0.3

#10 Updated by JiuG Neiva almost 7 years ago

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!

#11 Updated by JiuG Neiva almost 7 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

#12 Updated by JiuG Neiva almost 7 years ago

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

#13 Updated by JiuG Neiva almost 7 years ago

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

#14 Updated by Fernando Hartmann almost 7 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.

#15 Updated by Aurélien Appéré over 6 years ago

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

#16 Updated by evandro bubiak almost 5 years ago

still occurs on version 2.x

#17 Updated by Daniel Felix almost 5 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?

#18 Updated by Sebastian Hucke almost 5 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.

@JPL: 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 Felix: +1 for your reorganization option.

#19 Updated by Jean-Philippe Lang almost 5 years ago

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

Also available in: Atom PDF