View Issue Details

IDProjectCategoryView StatusLast Update
0008820mantisbtrelationshipspublic2010-02-20 11:40
Reportercdownie Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0008820: Copy Relationship
Description

When an issue is copied, it should automatically create a relationship indicating it as a duplicate between the two issues.

TagsNo tags attached.
Attached Files
bug_api.patch (366 bytes)   
Index: bug_api.php
===================================================================
--- bug_api.php	(revision 4931)
+++ bug_api.php	(working copy)
@@ -593,6 +593,9 @@
 			}
 		}
 
+		#Add new duplicate relationship
+		relationship_add( $t_bug_id, $t_new_bug_id, BUG_HAS_DUPLICATE );		
+
 		# Copy bugnotes
 		if ( $p_copy_bugnotes ) {
 			$query = "SELECT *
bug_api.patch (366 bytes)   

Activities

giallu

giallu

2008-01-28 18:48

reporter   ~0016866

I guess by "Copied" you mean the "Create Clone" command.

Now, what if I wanted to clone an issue and set the new one something else than "duplicate", let's say, "related to"?

cdownie

cdownie

2008-01-29 08:40

reporter   ~0016875

I agree that the Create Clone should work as it currently does, allowing you to choose the relationship. However I'm not referring to the 'Create Clone'. I am talking about the dropdown box on the bottom of the bug list 'View Issues' that allows you to deal with issues in bulk. One of the options in the dropdown is 'Copy', which lets you create a duplicate of the selected bugs.

Since this is a copy, and you are unable to modify any of the attributes in the bug as you are able to do in 'Create Clone', it would make sense to me that they be marked as duplicates.

RoboDoc

RoboDoc

2009-12-16 07:49

reporter   ~0023913

In our projects, we use the 'create clone' feature to clone an issue, then change SOME of the text (instead of reporting an entirely new issue), making the "cloned" issue a completely different (and often unique) issue - not necessarily related to the issue from which it was cloned.

We do this to save time when having to submit tons of issues, e.g. when we need to perform the same maintenance operation on 70 servers, and want to include each server's hostname in the summary field.

In case we need a relationship flag on the "clone", we set that value manually - before submitting the form, thereby creating a unique clone with correct relationship data - all in one 'submit'-operation. Often, we set this to "child of", just to group them together while doing heavy system maintenance.

Today's solution is perfect.

If you want the "duplicate" form to have "duplicate of" set as default relationship-choice (drop down menu), then it's fairly simple to define or change this behavior in the code.

I agree that it might be useful for some, though, to be able to define this behavior in the configuration files.

e.g. "$default_child_bug_relationship = s_duplicate_of;", etc. :)

dylanc

dylanc

2010-02-20 11:40

reporter   ~0024449

Slightly related but I added a feature to our local version of mantis to copy all parent relationships from the cloned issue. This makes it easier to duplicate an issue at the "same level" in the hierarchy.

You can of course select "none" on the parents to not hook up those parent relationships.

If anyone is interested in adding this to the trunk I will attach the simple patch. I also added the display of the bug's summary alongside each relationship in the report issue form to make it easier to understand.