Defect #22022

Issue shows wrong in wrong parent subtasks list

Added by Lifecycle Software almost 2 years ago. Updated 6 months ago.

Status:Needs feedbackStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution: Affected version:3.2.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?

image_thumb[13].png (53 KB) Lifecycle Software, 2016-02-12 15:51

subs.png (14.6 KB) Toshi MARUYAMA, 2016-02-12 16:26

subs1.png (13.7 KB) Toshi MARUYAMA, 2016-02-12 16:38

subs2.png (14.6 KB) Toshi MARUYAMA, 2016-02-12 16:38

broken-parent.png (39.3 KB) Sebastian Paluch, 2016-07-05 12:18

History

#1 Updated by Toshi MARUYAMA almost 2 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"?

#2 Updated by Toshi MARUYAMA almost 2 years ago

Going deeper in the analisys..

I cannot understand what you are trying.
What values are lft and rgt?

#3 Updated by Lifecycle Software almost 2 years ago

I mean "THAT" subtasks list

#4 Updated by Lifecycle Software almost 2 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]

#5 Updated by Toshi MARUYAMA almost 2 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

#6 Updated by Lifecycle Software almost 2 years ago

It happened after moving multiple times the parent task by REST API

#7 Updated by Toshi MARUYAMA almost 2 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

#8 Updated by Lifecycle Software almost 2 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

#9 Updated by Lifecycle Software almost 2 years ago

Seems like somewhat related to Issues visible accross all project?!

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.

#10 Updated by Sebastian Paluch over 1 year ago

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.

#11 Updated by Serghei Zagorinyak about 1 year 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.

#12 Updated by Guillermo ML 6 months 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.

Also available in: Atom PDF