--------------------------------------------------------------------------------
Same to me
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Same here. I would like to have this feature, it seems really useful for me.
--------------------------------------------------------------------------------
+Comment:+
* +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

+Workaround Details:+
* 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")

--------------------------------------------------------------------------------
The problem seems to come up when issue relations are in place _while_ trying to establish a parent-child construction by changing the parent issue field value of the child-to-be issue. If the parent-child construction is set first, issue relations among child issues can be configured flawlessly.
Note: this only applies to issue relations among child-issues; relations between the parent and its child(s) is not supported (and has never been supported).
--------------------------------------------------------------------------------
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":http://plan.io) 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.
--------------------------------------------------------------------------------
Confirmed, happens when setting a parent

# to an issue which has a relation to an issue which has a parent
# because of 1. and the fact that the parent issue is set to each one by one, to issues which already have mutual relations

--------------------------------------------------------------------------------
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.

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).
--------------------------------------------------------------------------------
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?

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, version#80; 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, version#80; 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.
--------------------------------------------------------------------------------
Sorry for the delay.

OK, so here's the proposed patch. I've tested the case, described in the Defect, and the problem no longer occurs. Although I definitely did not check all the possible cases.

All the "issue_test.rb" tests are successful with this patch; although I had to change one of them (see above). Also I've added one-line comments for 2 of the test-cases - I think it will be easier for the contributors to see, why is this test here.

Looking forward for your feedback!
--------------------------------------------------------------------------------
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.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
This is fixed by r15056. Tests were added for the use cases reported here.

What differs from the proposed pacth is that blocks/blocked by relations are now totally independant of parent/subtasks relations as Redmine does not block the closing of parent issues in any way.

And it was important to keep #test_setting_parent_to_a_dependent_issue_should_not_validate as is for the reasons now explained in comments. It was failing with the proposed change.

Kirill, thanks for your help in fixing this issue.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
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.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,13586,Circular loop testing prevents precedes/follows relation between subtasks
relates,Closed,14015,Ruby hangs when adding a subtask
relates,Closed,17580,After copying a task, setting the parent as the orignal task's parent triggers an error
relates,Closed,8628,"Related to" reference may yield circular dependency error message
duplicates,Closed,15599,tickets that are related to each other block a declaration of parent task for them (error: invalid task)
duplicates,Closed,17845,Assigning parent task fails when a related issue is yet a sub issue of the new parent task
duplicates,Closed,18403,Can't change parent task if an issue has some relations
duplicates,Closed,19406,Cannot set multiple "tasks with precedes/follows relationship" to *all* become child-tasks of some parent
duplicates,Closed,20750,linking a copied issue to a superordinate ticket does not work
duplicates,Closed,15320,Changing Child's Parent Ticket Field To Parent's Parent fails.
duplicates,Closed,19627,Cannot set task.Parent = Grandparent
duplicates,Closed,21758,Cannot specify parent task if has linked related issue
duplicates,Closed,21558,The issue parent has in most caes to be deleted before assigning a new parent.
duplicates,Closed,22774,"Parent task is invalid" message when setting parent to root issue after setting to a child of the root.
duplicates,Closed,25137,Assigning a parent in issue properties does not work (Error "Parent task is invalid") although the Parent exists