Defect #12846
open
sub-issues being rendered under wrong parent issue
0%
Description
I have a group of issues that seem to be rendering as associated with the wrong parent issue.
This query on the database returns zero items:
select count(0) from issues where root_id=19649 or parent_id= 19649 ;
Rendering the URL: http://my_redmine/issues/19649 shows this list of sub-tasks associated with this issue.
19547, 19121, 19099, 18966, 18956, 18825, 18572, 17887, 17799, 17795, 17601, 18532, 20011
Yet, if I plug the ids of those listed sub-tasks into a database query like this:
select id, parent_id, root_id from issues where id in (19547, 19121, 19099, 18966, 18956, 18825, 18572, 17887, 17799, 17795, 17601, 18532, 20011);
I get this result:
+ -------+-------------+---------+
| id | parent_id | root_id |
+ -------+-------------+---------+
17601 | 19925 | 19925
17795 | 19925 | 19925
17799 | 19925 | 19925
17887 | 19925 | 19925
18532 | 19925 | 19925
18572 | 19925 | 19925
18825 | 19925 | 19925
18956 | 19925 | 19925
18966 | 19925 | 19925
19099 | 19925 | 19925
19121 | 19925 | 19925
19547 | 19925 | 19925
20011 | 19925 | 19925
+-------+-----------+---------+
13 rows in set (0.00 sec)
19649 is also a sub-task of 19925 but 19649 is not a parent for any subtask. It would seem that rendering 19649 should show only that issue without any sub-tasks.
I am running tagged version 2.0.4. Is this the expected behavior or perhaps a bug?
Related issues
Updated by Jan Niggemann (redmine.org team member) almost 12 years ago
We're talking about nested sets here, can you please include lft and rgt in your query?
If you ORDER BY lft you already have the basic hierarchy...SELECT id, parent_id, root_id, lft, rgt from issues WHERE root_id=53 ORDER by lft
Updated by Paul Wilson almost 12 years ago
Is this what you are requesting? Here is the same query with lft and rgt included, ordered by lft:
select id, parent_id, root_id, lft, rgt from issues where id in (19547, 19121, 19099, 18966, 18956, 18825, 18572, 17887, 17799, 17795, 17601, 18532, 20011) order by lft;
select id, parent_id, root_id, lft, rgt from issues where id in (19547, 19121, 19099, 18966, 18956, 18825, 18572, 17887, 17799, 17795, 17601, 18532, 20011) order by lft;
+---------+------------+---------+-------+------+
id | parent_id | root_id | lft | rgt
+---------+------------+---------+-------+------+
19547 | 19925 | 19925 | 81 | 82 |
19121 | 19925 | 19925 | 83 | 84 |
19099 | 19925 | 19925 | 85 | 86 |
18966 | 19925 | 19925 | 87 | 88 |
18956 | 19925 | 19925 | 89 | 90 |
18825 | 19925 | 19925 | 91 | 92 |
18572 | 19925 | 19925 | 93 | 94 |
17887 | 19925 | 19925 | 95 | 96 |
17799 | 19925 | 19925 | 97 | 98 |
17795 | 19925 | 19925 | 99 | 100 |
17601 | 19925 | 19925 | 101 | 102 |
18532 | 19925 | 19925 | 103 | 104 |
20011 | 19925 | 19925 | 105 | 106 |
+---------+------------+---------+-------+------+
13 rows in set (0.01 sec)
Updated by
Updated by Paul Wilson almost 12 years ago
I agree, it could be, and likely is, related to #11319.
I fixed this one occurance by manually updating my issue 19649 and setting the value of rgt to the value of lft +1. Now both of my issues 19649 and 19925 render correctly.
I can't document for sure how this happened but I suspect that at one time:
19649 had several sub-tasks associated with it
those sub-tasks were moved to a different parent task
19649 was also added as a sub-task to this new parent task
issue 19649 didn't get updated to reflect the loss of its sub-tasks
Updated by Toshi MARUYAMA almost 10 years ago
- Related to Defect #6320: Subtasks do not appear under parent task in Issues view added