0000638: Copy and Paste of a boolean operation moves children to new object - FreeCAD Tracker

NOTICE: Migration to GitHub Issues

On Feb 7, 2022, the FreeCAD project migrated all issues from this site at tracker.freecad.org to our main GitHub repository. All new bugs must be submitted there.
This Mantis repository is in read-only mode and will be retained for reference as long as it is useful.

For details please see the announcement at the Forums: https://forum.freecadweb.org/viewtopic.php?p=555883#p555883

ID	Project	Category	View Status	Date Submitted	Last Update

0000638	FreeCAD	Bug	public	2012-03-14 01:57	2013-05-17 09:33

Reporter	wjl	Assigned To	~~Jriegel~~
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	0.12
Fixed in Version	0.14

Summary	0000638: Copy and Paste of a boolean operation moves children to new object
Description	Found in Debian package version 0.12.5284-dfsg-4. When copying and pasting a boolean operation, all of the children of the copied object are moved and reparented under the newly created object. This is highly annoying, especially when copying a boolean operation object down in a nested tree of operations.
Tags	No tags attached.

FreeCAD Information

shoogen 2012-03-15 13:10 developer ~0001777	If multiple objects claim a child, the last one wins. As a workaround, you can make a parent 'win' once by entering and leavin the 'transform' mode (in the context menu in the tree view)

normandc 2012-03-22 23:24 manager ~0001806	If you don't need for your copy to be linked to the original, you can create a non-parapetric copy by going to "Part --> Create simple copy" menu. In any case, this is not a bug IMHO, but a design choice.

djreichel 2012-03-23 22:33 reporter ~0001809	I found the same thing happens when copying a pad, extrusion and cut. (maybe more, but those are ones I tested) The child entity becomes the child of the parent created by the copy. The original parent then has no child. If the parent is expanded in the project browser and both the parent and the child may be manually selected for copy, the copy will create a new parent and a new child. The behavior is identical with my "recent git" running on Ububtu 10.04 and Fedora 16 To my way of thinking, this behavior is counter intuitive. When an entity is selected for copy, one expects that by default the children would be selected recursively. On the other hand, it is useful when deleting a pad/boolean/etc to not delete the children by default. Perhaps a useful and easy to implement design would be to only select visible child nodes for actions such as copy/paste/delete. This way the user sees the selection take place as the parent is selected. If the user wants the child nodes selected, he can expand the item. Of course items may be selected/de-selected by ctrl-LMB.

~~Jriegel~~ 2012-12-20 22:01 administrator ~0002726	The copy mechanism is indeed a problem if there is a deep linkage. that have to be verified for all kind of objects..

wmayer 2013-05-17 09:31 administrator ~0003169	Copy&Paste makes a deep copy now and thus solves this issue.

Date Modified	Username	Field	Change
2012-03-14 01:57	wjl	New Issue
2012-03-15 13:10	shoogen	Note Added: 0001777
2012-03-22 23:24	normandc	Note Added: 0001806
2012-03-23 22:33	djreichel	Note Added: 0001809
2012-12-20 22:01	~~Jriegel~~	Note Added: 0002726
2012-12-20 22:01	~~Jriegel~~	Assigned To	=> Jriegel
2012-12-20 22:01	~~Jriegel~~	Status	new => assigned
2013-05-17 09:31	wmayer	Note Added: 0003169
2013-05-17 09:33	wmayer	Status	assigned => closed
2013-05-17 09:33	wmayer	Resolution	open => fixed
2013-05-17 09:33	wmayer	Fixed in Version	=> 0.14