View Issue Details

IDProjectCategoryView StatusLast Update
0011375mantisbtrelationshipspublic2015-06-14 09:49
Reporterdoot Assigned Todhx  
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Target Version1.2.0Fixed in Version1.2.0 
Summary0011375: Users that are monitoring a bug should be transferred if the bug is closed as a duplicate
Description

This is a feature request stemming from http://bugs.centos.org/view.php?id=3931

Basically, if a bug X is resolved as a duplicate of bug Y, any and all users that are listed as monitoring bug X should be monitoring bug Y instead.

Additional Information

A patch is attached that has been tested against 1.1.8

Tagspatch

Relationships

related to 0011449 closeddhx application error 0000401 when resolving as a duplicate 
related to 0011834 new Include users from duplicate bugs in notifications 
related to 0012095 closeddhx bug_monitor_copy() should check users exist 
related to 0019839 closedatrol Unnecessary data created when resolving issues as duplicate 

Activities

doot

doot

2010-01-10 13:45

reporter  

bug_api.diff (1,295 bytes)   
--- mantisbt-1.1.8/core/bug_api.php     2009-06-08 22:48:31.000000000 +0300
+++ mantis/core/bug_api.php     2010-01-10 18:18:01.000000000 +0200
@@ -1280,6 +1280,22 @@
                                        history_log_event_special( $p_duplicate_id, BUG_ADD_RELATIONSHIP, BUG_HAS_DUPLICATE, $p_bug_id );
                                }
                        }
+
+                       # -------------- CentOS #3931
+                        # Patched by mark@mark.org.il
+                        $query = sprintf("SELECT *
+                                          FROM %s
+                                          WHERE bug_id = %d", config_get( 'mantis_bug_monitor_table' ) , $p_bug_id);
+                        $result = db_query( $query );
+                        $t_count = db_num_rows( $result );
+
+                        for ( $i = 0; $i < $t_count; $i++ ) {
+                                $row = db_fetch_array($result);
+                               bug_unmonitor($p_bug_id, $row['user_id']);
+                               bug_monitor($p_duplicate_id, $row['user_id']);
+                        }
+                        ## END PATCH
+

                        bug_set_field( $p_bug_id, 'duplicate_id', (int)$p_duplicate_id );
                }
bug_api.diff (1,295 bytes)   
jreese

jreese

2010-01-11 09:51

reporter   ~0024128

Targetting for 1.3.x, the next feature release.

dhx

dhx

2010-01-14 08:19

reporter   ~0024146

This is the code used in the bug_copy() function (bug_api.php) to copy the bug monitor list to a new (copied) bug:

# Copy users monitoring bug
if( $p_copy_monitoring_users ) {
    $query = &quot;SELECT *
                  FROM $t_mantis_bug_monitor_table
                  WHERE bug_id = &quot; . db_param();
    $result = db_query_bound( $query, Array( $t_bug_id ) );
    $t_count = db_num_rows( $result );

    for( $i = 0;$i &lt; $t_count;$i++ ) {
        $t_bug_monitor = db_fetch_array( $result );
        $query = &quot;INSERT INTO $t_mantis_bug_monitor_table
                     ( user_id, bug_id )
                     VALUES ( &quot; . db_param() . ', ' . db_param() . ')';
        db_query_bound( $query, Array( $t_bug_monitor['user_id'], $t_new_bug_id ) );
    }
}

I'm happy with the patch, with the exception of these minor points:

  • The use of sprintf() instead of db_param() to insert values into a query
  • The use of db_query() instead of db_query_bound() - this is essentially the same point as above
  • The use of config_get() instead of db_get_table( 'bug_monitor' )

I'll try and make those changes shortly and commit this feature to the 1.3.x branch. Thanks for bringing this useful idea up - and providing a patch to make it happen!

doot

doot

2010-01-14 08:26

reporter   ~0024147

No problem -- sorry for not following your coding conventions but it was a late-night kludge and is reasonably safe. :)

dhx

dhx

2010-01-14 08:30

reporter   ~0024148

Actually I think it may be better to introduce a new function like bug_monitor_copy() - or a similar name - to allow us to reuse this functionality elsewhere in a standard form. It's clear we're going to need to perform this copying of the bug monitor list quite a few times throughout the code.

And now I think about it, I tend to disagree with removing users from the bug monitor list for issues that are marked as duplicates. There is a possibility that someone could still perform actions on an issue already resolved/closed as being a duplicate. In which case, users may want to know about those changes. In particular, if someone decides to unduplicate two bug reports, people monitoring each bug before they were marked as duplicates should still be monitoring the individual bugs they signed up for.

Do my suggestions here sound OK?

dhx

dhx

2010-01-14 08:36

reporter   ~0024149

Well if you look at the Mantis code base, you'll see not even the current developers can agree on coding conventions! There isn't any expectation on users supplying patches to be 100% up to speed on Mantis' conventions. I wasn't trying to come across as sounding harsh or ungrateful :)

Thanks again for your help with improving Mantis.

One final suggestion I have is to investigate using git to maintain your local fork of Mantis. It'll make it much easier to pick the stable 1.2.x branch as a base, then backport new feature patches from 1.3.x (and your own) on top of it. I guess it depends on how many patches you manage in your local fork vs. the cost of learning how to use git.

doot

doot

2010-01-14 09:05

reporter   ~0024152

Adding bug_monitor_copy() would probably be best, perhaps with a boolean $move parameter?

As for using git, I'm familiar with it but I don't really maintain any local patches or deployments of Mantis -- the issue just came up on the CentOS install and I tried to resolve it ad-hoc.

toracat

toracat

2010-01-14 10:35

reporter   ~0024153

Hi, I'm the one who originally filed this request at the CentOS bug tracker.

What I meant by "transfer" was actually "copy" the monitor list because that makes it a real duplicate. :-)

I found this feature quite important from what I knew with bugzilla.

Thanks for the quick response. I look forward to the updated version of mantis.

dhx

dhx

2010-01-15 06:39

reporter   ~0024156

Committed to 1.3.x and also backported to the 1.2.x branch because it is something that strikes me as being more of a defect than a feature.

Note that if you need to MOVE (rather than COPY) the bug monitor list between two bugs, you can easily do so by first calling bug_monitor_copy($source_bug_id, $destination_bug_id) followed by bug_unmonitor($source_bug_id, null). If the second parameter of bug_unmonitor isn't specified, it'll remove EVERY user from the bug monitor list for a given bug.

Thanks for your help and assistance with this fix.

There are more details in the commit message if you're interested in the reasoning behind not using bug_monitor_copy(...) within relationship_api.php

Related Changesets

MantisBT: master-1.2.x 8a9f6d05

2010-01-15 10:04:47

dhx

Details Diff
Fix 0011375: Copy list of users monitoring duplicate bug to original bug

If a bug X is resolved as being a duplicate of bug Y, any users that are
monitoring bug X should automatically start monitoring bug Y (if they
aren't already).

This solution isn't perfect because it's still possible to manually add
a "duplicate" relationship within the relationship table or use
bug_update_page.php to manually resolve an issue as being a duplicate.

This copying of the bug monitor list thus only occurs when
bug_resolve(...) is called - ie. when a bug is resolved using the bug
status dropdown and a duplicate bug ID is provided on the following
bug_change_status_page.php page.

A new bug_monitor_copy( source_bug_id, destination_bug_id ) function has
been placed into bug_api.php for use in other cases too. Currently the
only other use of this function is when copying/cloning a bug.

One may wonder why a call to bug_monitor_copy() isn't made somewhere
within relationship_api.php to catch all cases where a duplicate
relationship is created. The reason is to do with maintaining low
coupling - relationship API shouldn't need to know about the logic of
duplicate bugs and bug monitoring lists.

Thanks to Akemi Yagi for reporting this issue on the CentOS bug tracker
at http://bugs.centos.org/view.php?id=3931 and to Mark Rappoport for
passing the matter upstream to MantisBT, providing an initial patch in
the process.
Affected Issues
0011375
mod - core/bug_api.php Diff File

MantisBT: master 8815b9d0

2010-01-15 10:04:47

dhx

Details Diff
Fix 0011375: Copy list of users monitoring duplicate bug to original bug

If a bug X is resolved as being a duplicate of bug Y, any users that are
monitoring bug X should automatically start monitoring bug Y (if they
aren't already).

This solution isn't perfect because it's still possible to manually add
a "duplicate" relationship within the relationship table or use
bug_update_page.php to manually resolve an issue as being a duplicate.

This copying of the bug monitor list thus only occurs when
bug_resolve(...) is called - ie. when a bug is resolved using the bug
status dropdown and a duplicate bug ID is provided on the following
bug_change_status_page.php page.

A new bug_monitor_copy( source_bug_id, destination_bug_id ) function has
been placed into bug_api.php for use in other cases too. Currently the
only other use of this function is when copying/cloning a bug.

One may wonder why a call to bug_monitor_copy() isn't made somewhere
within relationship_api.php to catch all cases where a duplicate
relationship is created. The reason is to do with maintaining low
coupling - relationship API shouldn't need to know about the logic of
duplicate bugs and bug monitoring lists.

Thanks to Akemi Yagi for reporting this issue on the CentOS bug tracker
at http://bugs.centos.org/view.php?id=3931 and to Mark Rappoport for
passing the matter upstream to MantisBT, providing an initial patch in
the process.
Affected Issues
0011375
mod - core/bug_api.php Diff File

MantisBT: master-1.2.x 185b4b26

2010-02-07 11:52:11

dhx

Details Diff
Issue 0011375: Narrow down SQL SELECT to get minimum columns

We only need to the user_id column, not bug_id or other columns in the
bug_monitor table.
Affected Issues
0011375
mod - core/bug_api.php Diff File

MantisBT: master 83b89fcd

2010-02-07 11:52:11

dhx

Details Diff
Issue 0011375: Narrow down SQL SELECT to get minimum columns

We only need to the user_id column, not bug_id or other columns in the
bug_monitor table.
Affected Issues
0011375
mod - core/bug_api.php Diff File

Issue History

Date Modified Username Field Change
2010-01-10 13:45 doot New Issue
2010-01-10 13:45 doot File Added: bug_api.diff
2010-01-11 09:51 jreese Note Added: 0024128
2010-01-11 09:51 jreese Status new => acknowledged
2010-01-11 09:51 jreese Target Version => 1.3.0-beta.1
2010-01-14 08:08 dhx Tag Attached: patch
2010-01-14 08:19 dhx Note Added: 0024146
2010-01-14 08:20 dhx Assigned To => dhx
2010-01-14 08:20 dhx Status acknowledged => assigned
2010-01-14 08:26 doot Note Added: 0024147
2010-01-14 08:30 dhx Note Added: 0024148
2010-01-14 08:36 dhx Note Added: 0024149
2010-01-14 09:05 doot Note Added: 0024152
2010-01-14 10:35 toracat Note Added: 0024153
2010-01-15 06:35 dhx Status assigned => resolved
2010-01-15 06:35 dhx Fixed in Version => 1.2.2
2010-01-15 06:35 dhx Resolution open => fixed
2010-01-15 06:39 dhx Note Added: 0024156
2010-01-15 06:39 dhx Target Version 1.3.0-beta.1 => 1.2.2
2010-01-15 06:40 dhx Changeset attached master-1.2.x 8a9f6d05 =>
2010-01-15 06:40 dhx Changeset attached master 8815b9d0 =>
2010-02-07 06:44 dhx Relationship added related to 0011449
2010-02-07 07:10 dhx Changeset attached master-1.2.x 185b4b26 =>
2010-02-07 07:10 dhx Changeset attached master 83b89fcd =>
2010-02-22 14:34 jreese Status resolved => closed
2010-04-23 04:26 dhx Relationship added related to 0011834
2010-06-19 00:27 dhx Relationship added related to 0012095
2015-06-14 09:49 atrol Relationship added related to 0019839