Project

General

Profile

Actions

Defect #5803

closed

Precedes/Follows Relationships Broke

Added by Howard Mall over 13 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Issues
Target version:
Start date:
2010-07-01
Due date:
% Done:

0%

Estimated time:
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

Files

issue.rb.diff (1.11 KB) issue.rb.diff Yuki Kita, 2010-07-05 11:33
Redmine_issue_5803.pdf (206 KB) Redmine_issue_5803.pdf JiuG Neiva, 2011-02-07 19:59

Related issues

Related to Redmine - Feature #4590: Precede-Follow relation should move following issues when rescheduling issue earlierClosedJean-Philippe Lang2010-01-15

Actions
Related to Redmine - Defect #5398: Can not reschedule the start date of following issues at onceNew2010-04-29

Actions
Actions #1

Updated by Howard Mall over 13 years ago

  • Assignee set to Jean-Philippe Lang
Actions #2

Updated by Yuki Kita over 13 years ago

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

Actions #3

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

Actions #4

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

Actions #5

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

Actions #6

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

Actions #7

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

Actions #8

Updated by Jean-Philippe Lang over 13 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.

Actions #9

Updated by Eric Davis over 13 years ago

  • Status changed from Resolved to Closed

Merged into 1.0-stable for release in 1.0.3

Actions #10

Updated by JiuG Neiva about 13 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!

Actions #11

Updated by JiuG Neiva about 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

Actions #12

Updated by JiuG Neiva about 13 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
Actions #13

Updated by JiuG Neiva about 13 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

Actions #14

Updated by Fernando Hartmann about 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.

Actions #15

Updated by Aurélien Appéré over 12 years ago

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

Actions #16

Updated by evandro bubiak over 11 years ago

still occurs on version 2.x

Actions #17

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?

Actions #18

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.

Actions #19

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.

Actions

Also available in: Atom PDF