View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0011375 | mantisbt | relationships | public | 2010-01-10 13:45 | 2015-06-14 09:49 |
Reporter | doot | Assigned To | dhx | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | fixed | ||
Target Version | 1.2.0 | Fixed in Version | 1.2.0 | ||
Summary | 0011375: 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 | ||||
Tags | patch | ||||
Attached Files | 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 ); } | ||||
related to | 0011449 | closed | dhx | application error 0000401 when resolving as a duplicate |
related to | 0011834 | new | Include users from duplicate bugs in notifications | |
related to | 0012095 | closed | dhx | bug_monitor_copy() should check users exist |
related to | 0019839 | closed | atrol | Unnecessary data created when resolving issues as duplicate |
Targetting for 1.3.x, the next feature release. |
|
This is the code used in the bug_copy() function (bug_api.php) to copy the bug monitor list to a new (copied) bug:
I'm happy with the patch, with the exception of these minor points:
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! |
|
No problem -- sorry for not following your coding conventions but it was a late-night kludge and is reasonably safe. :) |
|
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? |
|
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. |
|
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. |
|
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. |
|
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 |
|
MantisBT: master-1.2.x 8a9f6d05 2010-01-15 05:04 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 05:04 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 06:52 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 06:52 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 |