Defect #5524

Update_parent_attributes doesn't work for the old parent issue when reparenting

Added by Fri Flaj over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:2010-05-14
Priority:HighDue date:
Assignee:Eric Davis% Done:

100%

Category:Issues
Target version:1.0.0 (RC)
Resolution:Fixed Affected version:

Description

Try the following scenario:
  • Create issue "Parent 1"
  • Create issue "Parent 2"
  • Create subissue "Child" on "Parent 2" and set its estimated hours to 5

Current situation: Parent 1: 0hrs, Parent 2: 5 hrs, Child: 5 hrs

Now change parent for Child to "Parent 1"

Current situation: Parent 1: 5hrs, Parent 2: 5 hrs, Child: 5 hrs

5524_svn.diff Magnifier (2.03 KB) Jean-Baptiste Barth, 2010-06-08 19:50

Associated revisions

Revision 3821
Added by Eric Davis over 7 years ago

Recalculate inherited attributes on parents when a child is moved under a new parent. #5524

Contributed by Jean-Baptiste Barth.

History

#1 Updated by Fri Flaj over 7 years ago

I think this could be solved by doing something like the following when an issue is saved:

if <issue has parent> and <new parent != current parent>
p = <parent>
c = <children excluding tree starting at issue being reparented>
l = <leaves excluding tree starting at issue being reparented>
<update parent attributes as usual>
end

this will not disturb the usual workflow, and will work even if the issue being reparented is the last sub issue on its parent. I just don't know where to stick this behaviour.

#2 Updated by Fri Flaj over 7 years ago

I had expected the following to work:

before_save :store_parent
after_save :fix_old_parent

def store_parent
if self.parent_id_was && !(self.parent_id_was == self.parent_issue_id)
@old_parent = self.parent_id_was
else
@old_parent = nil
end
end

def fix_old_parent
if @old_parent
dummy_child = Issue.new (:parent_id => @old_parent)
dummy_child.instance_eval { update_parent_attributes }
end
end

I can see the methods being called when I add logging, but the estimated hours remain as they are.

#3 Updated by Jean-Baptiste Barth over 7 years ago

Reproduced here on current trunk. I leave a patch to solve this problem, a unit test included, all tests passing succesfully on my config.

Emiliano: maybe you can apply this and see if it works for you..

#4 Updated by Fri Flaj over 7 years ago

Seems to do the job for me. Is there a timeline for this to be included in RM trunk?

#5 Updated by Felix Schäfer over 7 years ago

  • Assignee set to Eric Davis
  • Target version set to 1.0.0 (RC)

My best bet to get this merged would be Eric Davis, though he is under a lot of stress from his work and redmine at the moment. I think this is important enough that it should be fixed for 1.0.0 though.

#6 Updated by Eric Davis over 7 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
  • Resolution set to Fixed

Applied in r3821. Thank you for the test in the patch, I had trouble understanding what this bug was doing until I read the test case.

Also available in: Atom PDF