Lifecycle Software wrote:
> But the problem is that Issue 639 is showing in the subtasks list of 735! Like this:
<pre>
732
734
735
639
766
</pre>
What do you mean "subtasks list"?
--------------------------------------------------------------------------------
> Going deeper in the analisys..

I cannot understand what you are trying.
What values are lft and rgt?
--------------------------------------------------------------------------------
I mean "THAT" subtasks list
--------------------------------------------------------------------------------
Also, giving the same data:

<pre>
2.2.3 :030 > expectedChilds = Issue.find_by_sql("SELECT `issues`.* FROM `issues` WHERE `issues`.`root_id` = 732 and parent_id = 766")
Issue Load (0.3ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`root_id` = 732 and parent_id = 766
=> [#<Issue id: 638, tracker_id: 2, project_id: 5, subject: "Deactivate Subscriber (RM-224)", description: "", due_date: "2016-02-11", category_id: 2, status_id: 5, assigned_to_id: 14, priority_id: 2, fixed_version_id: 10, author_id: 1, lock_version: 18, created_on: "2016-01-22 08:53:44", updated_on: "2016-02-12 14:13:09", start_date: "2016-02-09", done_ratio: 100, estimated_hours: 7.0, parent_id: 766, root_id: 732, lft: 6, rgt: 7, is_private: false, closed_on: "2016-02-12 14:13:09">, #<Issue id: 639, tracker_id: 2, project_id: 5, subject: "Reactivate Subscriber (RM-224)", description: "", due_date: "2015-12-23", category_id: 2, status_id: 5, assigned_to_id: 14, priority_id: 2, fixed_version_id: 10, author_id: 1, lock_version: 18, created_on: "2016-01-22 08:53:45", updated_on: "2016-02-12 14:13:09", start_date: "2015-12-17", done_ratio: 100, estimated_hours: 7.0, parent_id: 766, root_id: 732, lft: 8, rgt: 9, is_private: false, closed_on: "2016-02-12 14:13:09">]

2.2.3 :031 > expectedChilds.count
=> 2

2.2.3 :032 > expectedChilds[0]
=> #<Issue id: 638, tracker_id: 2, project_id: 5, subject: "Deactivate Subscriber (RM-224)", description: "", due_date: "2016-02-11", category_id: 2, status_id: 5, assigned_to_id: 14, priority_id: 2, fixed_version_id: 10, author_id: 1, lock_version: 18, created_on: "2016-01-22 08:53:44", updated_on: "2016-02-12 14:13:09", start_date: "2016-02-09", done_ratio: 100, estimated_hours: 7.0, parent_id: 766, root_id: 732, lft: 6, rgt: 7, is_private: false, closed_on: "2016-02-12 14:13:09">

2.2.3 :033 > expectedChilds[1]
=> #<Issue id: 639, tracker_id: 2, project_id: 5, subject: "Reactivate Subscriber (RM-224)", description: "", due_date: "2015-12-23", category_id: 2, status_id: 5, assigned_to_id: 14, priority_id: 2, fixed_version_id: 10, author_id: 1, lock_version: 18, created_on: "2016-01-22 08:53:45", updated_on: "2016-02-12 14:13:09", start_date: "2015-12-17", done_ratio: 100, estimated_hours: 7.0, parent_id: 766, root_id: 732, lft: 8, rgt: 9, is_private: false, closed_on: "2016-02-12 14:13:09">
</pre>

I can see that the real LFT and RGT are 6,7 and 7,8 but when you use the "descendats" calls (as used by the "Issue view controller", the SQL loaded looks different:
<pre>
2.2.3 :036 > parentIssue.descendants
Issue Load (1.1ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`root_id` = 732 AND (issues.lft > 23 AND issues.rgt < 26) ORDER BY `issues`.`lft` ASC
=> #<ActiveRecord::Relation []>
</pre>

And tries to load the nested list as "(issues.lft < 23 AND issues.rgt > 26)"...

[Edit: wrong copy&paste]
--------------------------------------------------------------------------------
I cannot reproduce.
!subs.png!

<pre>
sqlite> select id, lft, rgt, parent_id from issues where root_id = 46 order by lft;
46|1|10|
47|2|9|46
48|3|6|47
35|4|5|48
49|7|8|47
</pre>
--------------------------------------------------------------------------------
It happened after moving multiple times the parent task by REST API
--------------------------------------------------------------------------------
Sorry, I used wrong example.
This is new example.
!subs1.png!
<pre>
sqlite> select id, lft, rgt, parent_id from issues where root_id = 46 order by lft;
46|1|8|
47|2|7|46
48|3|4|47
49|5|6|47

</pre>

!subs2.png!
<pre>
sqlite> select id, lft, rgt, parent_id from issues where root_id = 46 order by lft;
46|1|10|
47|2|9|46
48|3|4|47
49|5|8|47
32|6|7|49

</pre>
--------------------------------------------------------------------------------
Toshi MARUYAMA wrote:
> Sorry, I used wrong example.
> This is new example.
> !subs1.png!
> [...]
>
> !subs2.png!
> [...]

Thanks you for your support!
Now try to move the 32 (actually child of 49) to child of 48 via a JSON REST submission

--------------------------------------------------------------------------------
Seems like somewhat related to message#38378

I fixed it doing ssh on my server, backed-up my production DB, logged in the "rail console production" and executing a "Issue.rebuilt_tree!"
I scheduled a daily night job with RUFUS SCHEDULER to fix this issue since we manage tasks using REST API a lot and this issue is recurrent.

Bye.
--------------------------------------------------------------------------------
I have the same problem.

An issue is shown in wrong hierarchy tree and subtasks list.

See attached picture. Parent Id (and entire chierachy) as shown on the top of an issues does not match parent shown when I go into edit mode. The one in Edit mode is correct one.

!broken-parent.png!
--------------------------------------------------------------------------------
Same here after upgrading from 2.6.8 to 3.3.0.
Adding subtasks to some issues with rather deep hierarchy (3-5 levels) results in new subtasks being displayed at a higher hierarchy level than required, while parent_id and root_id are specified correctly. I was unable to find what is causing this because it only happens for a rather small amount of issues.
--------------------------------------------------------------------------------
We have the same problem with 3.3.1.
We used the patch from Feature #24167 to repair broken hierarchies. That patch avoid us to spend hours repairing the complete issue's tree.
--------------------------------------------------------------------------------