Redmine

Same to me

Same here. I would like to have this feature, it seems really useful for me.

• +1 Same for us, this was working well >2.3.0
• we updated from V2.3.0 to V2.3.1 to solve this problem (and #13586)
• moving subtasks to another main task is a common usecase for us

• in V2.3.0 it was possible to workaround by 1. clearing the parant-task and than setting the new parent task
• but V2.3.1 seems to make the bug more serious, the workaround doesn't work any more (always "Parent task is invalid")

with patch from #14015 it is possible to set parent issue again, but icons are not displayed correctly, see http://www.redmine.org/issues/14015#note-7

forget my notes about missing icons. Now i've learned that icons are only displayed if the parent issue is above the issue. So if i sort on 'parent id' my parent issue is the first and all my sub issues are displayed with icons :-)

same here. For examle, I have tasks 1, 2, 3. 2 is child of 1, 2 is related to 3. When I try to move 3 to 1 as child, it says "Parent task is invalid". After removing relationship between 2 and 3, it works.

the problem seems to appear in line 579 of issue.rb. As I understand it's not a bug, but feature.
There is a function all_dependent_issues, which constructs array with all childs of issue we move and related to them issues. If the target parent issue appears in that array by some way (I think through related issues), error is thrown.
If we do not add related issues to all_dependent_issues, everything works just fine (to do that comment lines 923-936 in issue.rb).
I can missing something, but why we add related issues to all_dependent_issues? I don't see any logic of that.

We're (Planio) also seeing this problem, it's very strange because you can remove the relationship between the future siblings, make 2 issues siblings and re-add the relationship between the 2 siblings afterward.

Is there any way we can help with this or speed up things in any way?

Same problem here. A blocks B, and if I try to set A and B parent to C, I got an error: "Parent task is invalid"
As Felix said, the only workaround is to remove the issues relations and re-add them, which could be very painful.

I don't understand the Issue#all_dependent_issues method or where it's used well enough yet, so this has to be taken to a grain of salt, but removing the line source:/branches/2.3-stable/app/models/issue.rb@12213#L903 solves this problem. Be aware though: This is untested for everything else, so I can't say what other repercussions this has on other functions of Redmine.

+1
Here same issue arises which did not while we were using 2.2.x.
If all_dependent_issues(except) is universal as intended, except argument may be not provided correctly at usage. And probably, all_dependent_issues(except) should be called multiple times with different except s.

Issue#all_dependent_issues seems to be too complicated and unreasonable (and also it slows down the performance when creating or updating issues). This algorythm defines dependent issues term and says that it consists of parent, child and related issues of particular issue. In fact we shouldn't consider related issues as dependent issues.

Let's say we want B to make as child to A. The only checking we should do is to ensure that B doesn't already belong to the children tree of A and B doesn't have A in its own children tree. In fact this point is very different to issue relationships.

So I am definitely sure that we should remove from Issue#all_dependent_issues algorithm the lines deal with issue relationships. These lines are 926-940 in http://www.redmine.org/projects/redmine/repository/revisions/12213/entry/branches/2.3-stable/app/models/issue.rb. As i tested it seems to break nothing.

Also we may need to rewrite a bit this function because there will be no use of some logic and constants anymore.

I you need any help I can prepare patch.

Also confirm the behavior, removing relationship, adding parent, and re-creating relationship is a possible workaround for the time being. But that may send lots of undesired email notifications.

I'm running Redmine 2.3.1.stable. We experience this issue as well.

This workaround doesn't work
1) Remove any existing parent then save.
2) Add the new parent.

This workaround works
1) Remove any existing parent and related tasks.
2) Add the new parent and related tasks removed in step 1.

Additionally last week our server went into an infinite loop. Ruby processes maxed at 100% cpu and doesn't respond to new requests. This is probably related issue #14015 or #13586 which has been fixed in 2.3.2.

With Redmine 2.4, I also experience this bug. Workaround : first remove the related tasks, put them under the same parent, then add again the relation between the brother tasks.

Same here, in Redmine Version 2.5. I would like to have this feature, it seems really useful for me.

With Redmine 2.5.1, I also experience this bug. I would like to have this feature, it seems really useful for me.

Pierre Pretorius wrote:

1) Remove any existing parent and related tasks.

Ouch, ever since we got history on adding/removing related tasks, having to do things like this to fix relationship issues gets very noisy. :(

Those defects #13654 and #15320 are really annoying and prevents us to rearrange a hierarchie of issues. (we are using 2.4.1)
As stated above I am not sure that the piece of code that prevent creation of cycles should care about "linked issues" but only about parent-child relationships.

This issue is still reproducible in 2.5.2.stable; it's a pretty big show-stopper.

+1

+1

I got bit by this again today. My workaround for similar situations when Redmine won't let me relate ticket A to ticket B is to relate B to A. However since I was trying to change parent tickets I had to nuke all relations, and then "reparent" the ticket (as others have already said). I did not bother trying to add the relations back when I was done.

+1

Confirmed in Redmine 2.5.2.stable.13466. Really annoying.

+1

Confirmed in Redmine 2.5.2

Please fix it!

+1!

Etienne Rossignon wrote:

Those defects #13654 and #15320 are really annoying and prevents us to rearrange a hierarchie of issues. (we are using 2.4.1)
As stated above I am not sure that the piece of code that prevent creation of cycles should care about "linked issues" but only about parent-child relationships.

• Duplicates/Duplicated By
• Blocks/Blocked By
• Precedes/Follows
• Copied To/Copied From

Only the "Related To" linkage (which is symmetrical) should notionally ignore cycles and arguably the cycles should be managed on a per relationship type basis.

Parent-Child relationships are a traditional WBS structure feature and the Blocks/Blocked By and Precedes/Follows relationships are traditional scheduling relationships (the two should not interfere with each other).

Roger Griffiths wrote:

I agree that this should be resolved but some types of "linked issue" relationships do matter where cycles are concerned:-

• Duplicates/Duplicated By
• Blocks/Blocked By
• Precedes/Follows
• Copied To/Copied From

Only the "Related To" linkage (which is symmetrical) should notionally ignore cycles and arguably the cycles should be managed on a per relationship type basis.

Parent-Child relationships are a traditional WBS structure feature and the Blocks/Blocked By and Precedes/Follows relationships are traditional scheduling relationships (the two should not interfere with each other).

Any reason why Duplicates/Duplicated By and Copied To/Copied From should be considered as forming a hierarchy?

@ go2null wrote:

Roger Griffiths wrote:

...

Any reason why Duplicates/Duplicated By and Copied To/Copied From should be considered as forming a hierarchy?

• Duplicates/Duplicated By relation: enforces the auto-closure of duplicates when the duplicated issue is being closed.
• Copied To/Copied From: this relation is always added automatically when copying an issue (until r13668, 3.0.0; nevertheless, since issue copy is implemented as "old issue [Copy-action] issue new form + pre-filled properties (which can be manually changed) > new issue" issue copied to will logically always follow out of issue copied from (not taking manual relation changes into account here)).

+1
Fix please!

+1 - will be very useful

It is frustrating to see that this is still on priority "Normal" after two years of discussions and many duplicate reports.

It even seems that it is a regression (around 2.3.0/2.3.1), so it should receive some significant attention from developers.

+1 - This bug is really annoying since two years now...

Florian S. wrote:

+1 - This bug is really annoying since two years now...

+1

+1 This bug really disturbs many of my users.

+1 (because the reason is really unlogic and not recognizable)

+1 with Redmine 2.6.1

Mischa The Evil wrote:

@ go2null wrote:

Roger Griffiths wrote:

...

Any reason why Duplicates/Duplicated By and Copied To/Copied From should be considered as forming a hierarchy?

They are both tied to specific issue actions:

• Duplicates/Duplicated By relation: enforces the auto-closure of duplicates when the duplicated issue is being closed.
• Copied To/Copied From: this relation is always added automatically when copying an issue (until r13668, 3.0.0; nevertheless, since issue copy is implemented as "old issue [Copy-action] issue new form + pre-filled properties (which can be manually changed) > new issue" issue copied to will logically always follow out of issue copied from (not taking manual relation changes into account here)).

Duplicates/Duplicated By: OK.
Copied To/Copied From: I've had users copy an issue to make the copy the parent (as the copy from has children already), only to find out that they cannot.

+1

+1

+1, confirmed in redmine 3.1.1.

Hi all!

I believe that "all_dependent_issues" is not-so-well defined method.

I see that it includes children as dependent, while (as far as I understand) quite the opposite is true: parent task depends on it's children, and not vice versa. This basically follows out of assumption, that you cannot close (or solve) Parent task, until you have all the Children closed (or solved).

Am I wrong ? Can anyone comment on this ?

I would suggest to re-define (and re-implement) this method to return only really dependent issues - i.e., issues that cannot be closed or solved until you close or solve the issue in question (at least, concerning "parenthood", but normally it should also make distinction between dependency-neutral relations like "related" and dependency-critical relations like "blocked").

Any objections ? I would be happy to hear what the experts think about this.

Thanks a lot.

I propose to define a method "all_blocking_and_preceding_issues (issue)", that would return a collection of issues, by building a queue of:

- issue in question;
- issues, that have either "blocking" or "preceding" relation with any issue in the queue;
- issues, that are children of any issue in the queue.

(repeat building the queue until we cannot add any issue to the queue)

and the only check, that we have to have while adding a parent P to issue S, should be: make sure that P is not in 'all_blocking_and_preceding_issues (S)' (because that would create "closed dependency loop". All the other dependency checks are not relevant here.

Would be great to hear from the maintainers - is this acceptable approach ? I want to implement patch on this, but would be great to have a support from the experts.

There's unit test in "test/unit/issue_test.rb" called "test_setting_parent_to_a_dependent_issue_should_not_validate"

In this test, issue3 precedes issue1 and issue1 precedes issue2; and then issue2 is attempted to be set as a parent of issue3. The expected behaviour in a test is to FAIL this attempt.

As far I understand, there should be nothing wrong with issue3 preceding issue2 AND being a child of issue2; apparently, the test authors thought different about that.

May I ask what's the logic behind this test ? I see that it was added here (http://www.redmine.org/projects/redmine/repository/revisions/11641/diff/trunk/test/unit/issue_test.rb), although I don't exactly understand a point of test_setting_parent_to_a_dependent_issue_should_not_validate; test_setting_parent_should_not_allow_circular_dependency seems sufficient to mitigate the issue #8794

Please correct me if I am wrong on this

I want to suggest a patch for review; but the failing "test_setting_parent_to_a_dependent_issue_should_not_validate" test stops me from that.

the very point of my patch (as it should help solve the problem we're discussing here) is to ALLOW (incl. transient) non-blocking relationships between to-be-parent and to-be-child issues. The only case when setting P as parent to issue S should fail, is when P already BLOCKS or PRECEDES S (directly or transiently)

May I include removal or refactoring of test "test_setting_parent_to_a_dependent_issue_should_not_validate" in a patch ? Or what else should I do ?

Any suggestions are welcome.

Kirill Marchuk wrote:

May I include removal or refactoring of test "test_setting_parent_to_a_dependent_issue_should_not_validate" in a patch ?

Yes, that would be fine.

Yesterday, when I've proposed a patch, "rake test" was still running (it's all too slow on my machine), so I attached the patch before all the test were run.

At the end of it, it had 1 failure, something like "IssueNestedCollectionSet"

It was too late to investigate, and I will try to try it on master today.

Just FYI

Looks like the same happens with "master" on my machine:

1) Failure:
IssueNestedSetConcurrencyTest#test_concurrency [test/unit/issue_nested_set_concurrency_test.rb:45]:
Expected "Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: SELECT `issues`.`id` FROM `issues` WHERE (root_id IN (SELECT root_id FROM issues WHERE id IN (1031,1028)))  ORDER BY `issues`.`id` ASC FOR UPDATE" to be nil.

2) Failure:
IssueNestedSetConcurrencyTest#test_concurrent_subtasks_creation [test/unit/issue_nested_set_concurrency_test.rb:61]:
Expected "Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: SELECT `issues`.`id` FROM `issues` WHERE (root_id IN (SELECT root_id FROM issues WHERE id IN (1037)))  ORDER BY `issues`.`id` ASC FOR UPDATE" to be nil.

2 runs, 3 assertions, 2 failures, 0 errors, 0 skips

I have no ideas what to do with it, but I have a humble hope that this has nothing to do with my changes (as long as it's on master), so I would ask to review my patch and somehow push this process further..

I am pretty sure there're problems with coding style and other things, so I am ready to process this feedback

Hi all

Is there any timeline regarding patch review, or any other feedback ?

Thanks

Happy New Year everyone !

I hope in 2016 the patch will be reviewed.

Kirill Marchuk's patch works fine for me.

Kirill Marchuk wrote:

Looks like the same happens with "master" on my machine:

1) Failure:
IssueNestedSetConcurrencyTest#test_concurrency [test/unit/issue_nested_set_concurrency_test.rb:45]:
Expected "Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: SELECT `issues`.`id` FROM `issues` WHERE (root_id IN (SELECT root_id FROM issues WHERE id IN (1031,1028))) ORDER BY `issues`.`id` ASC FOR UPDATE" to be nil.

2) Failure:
IssueNestedSetConcurrencyTest#test_concurrent_subtasks_creation [test/unit/issue_nested_set_concurrency_test.rb:61]:
Expected "Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: SELECT `issues`.`id` FROM `issues` WHERE (root_id IN (SELECT root_id FROM issues WHERE id IN (1037))) ORDER BY `issues`.`id` ASC FOR UPDATE" to be nil.

2 runs, 3 assertions, 2 failures, 0 errors, 0 skips

Due to #19344.

The Problem still exists with Redmine 3.2.0.stable.

Thomas Koch wrote:

The Problem still exists with Redmine 3.2.0.stable.

The target revision appears to be 3.3.0.