Defect #22022
openIssue shows wrong in wrong parent subtasks list
0%
Description
To make it simple, I have this hierarchy
732 734 735 766
I have a Issue 639 which has a "parent_id"=766 so I'm supposing to see the hierarchy like that:
732 734 735 766 639
But the problem is that Issue 639 is showing in the subtasks list of 735! Like this:
732 734 735 639 766
From the rails console, I'll show the problem in more details:
2.2.3 :001 > issue = Issue.find_by_id(639) Issue Load (0.4ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`id` = 639 LIMIT 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: 2, assigned_to_id: 14, priority_id: 2, fixed_version_id: 10, author_id: 1, lock_version: 17, created_on: "2016-01-22 08:53:45", updated_on: "2016-02-12 11:35:41", start_date: "2015-12-17", done_ratio: 0, estimated_hours: 7.0, parent_id: 766, root_id: 732, lft: 8, rgt: 9, is_private: false, closed_on: nil> 2.2.3 :005 > issue.ancestors[issue.ancestors.count-1].id (0.3ms) SELECT COUNT(*) FROM `issues` WHERE `issues`.`root_id` = 732 AND (issues.lft < 8 AND issues.rgt > 9) Issue Load (0.5ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`root_id` = 732 AND (issues.lft < 8 AND issues.rgt > 9) ORDER BY `issues`.`lft` ASC => 735 2.2.3 :006 > issue.parent_id => 766
Here you can see that "issue" has a "parent_id" of 766, but it's nearest ancestor is 735!
Going deeper in the analisys..
2.2.3 :004 > parentIssue = Issue.find_by_id issue.parent_id Issue Load (0.6ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`id` = 766 LIMIT 1 => #<Issue id: 766, tracker_id: 2, project_id: 5, subject: "MW LowLevel Actors", description: "", due_date: "2016-02-11", category_id: 2, status_id: 1, assigned_to_id: 12, priority_id: 2, fixed_version_id: 10, author_id: 12, lock_version: 16, created_on: "2016-02-10 16:44:37", updated_on: "2016-02-12 11:35:41", start_date: "2015-12-17", done_ratio: 0, estimated_hours: nil, parent_id: 734, root_id: 732, lft: 23, rgt: 26, is_private: false, closed_on: nil> 2.2.3 :005 > parentIssue.parent_id => 734 2.2.3 :006 > ancestorIssue = issue.ancestors[issue.ancestors.count-1] (1.7ms) SELECT COUNT(*) FROM `issues` WHERE `issues`.`root_id` = 732 AND (issues.lft < 8 AND issues.rgt > 9) Issue Load (0.2ms) SELECT `issues`.* FROM `issues` WHERE `issues`.`root_id` = 732 AND (issues.lft < 8 AND issues.rgt > 9) ORDER BY `issues`.`lft` ASC => #<Issue id: 735, tracker_id: 2, project_id: 5, subject: "Executors", description: "", due_date: "2016-02-12", category_id: nil, status_id: 1, assigned_to_id: 28, priority_id: 2, fixed_version_id: 10, author_id: 12, lock_version: 11, created_on: "2016-02-08 15:50:40", updated_on: "2016-02-12 11:09:39", start_date: "2016-02-10", done_ratio: 0, estimated_hours: nil, parent_id: 734, root_id: 732, lft: 5, rgt: 10, is_private: false, closed_on: nil> 2.2.3 :007 > ancestorIssue.parent_id => 734
We can see that both realParent and ancestorParent have the same parent_id, as such they are brothers...
Why and how can I fix this one?
Files
Updated by Toshi MARUYAMA almost 9 years ago
- Status changed from New to Needs feedback
Lifecycle Software wrote:
But the problem is that Issue 639 is showing in the subtasks list of 735! Like this:
732 734 735 639 766
What do you mean "subtasks list"?
Updated by Toshi MARUYAMA almost 9 years ago
Going deeper in the analisys..
I cannot understand what you are trying.
What values are lft and rgt?
Updated by Lifecycle Software almost 9 years ago
- File image_thumb[13].png image_thumb[13].png added
I mean "THAT" subtasks list
Updated by Lifecycle Software almost 9 years ago
Also, giving the same data:
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">
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:
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 []>
And tries to load the nested list as "(issues.lft < 23 AND issues.rgt > 26)"...
[Edit: wrong copy&paste]
Updated by Toshi MARUYAMA almost 9 years ago
I cannot reproduce.
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
Updated by Lifecycle Software almost 9 years ago
It happened after moving multiple times the parent task by REST API
Updated by Toshi MARUYAMA almost 9 years ago
Sorry, I used wrong example.
This is new example.
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
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
Updated by Lifecycle Software almost 9 years ago
Toshi MARUYAMA wrote:
Sorry, I used wrong example.
This is new example.
[...]
[...]
Thanks you for your support!
Now try to move the 32 (actually child of 49) to child of 48 via a JSON REST submission
Updated by Lifecycle Software almost 9 years ago
Seems like somewhat related to
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.
Updated by Sebastian Paluch over 8 years ago
- File broken-parent.png broken-parent.png added
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.
Updated by Serghei Zagorinyak about 8 years ago
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.
Updated by Guillermo ML over 7 years ago
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.