View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0013816 | mantisbt | security | public | 2012-01-29 10:56 | 2014-09-23 18:05 |
Reporter | atrol | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.2.8 | ||||
Target Version | 1.2.9 | Fixed in Version | 1.2.9 | ||
Summary | 0013816: Enhance history when copying issues | ||||
Description | Coying issues using the "View Issues" page creates wrong/incomplete history Example: User B copies the issue using the "Copy" operation of the "View Issues" page. 1) you don't see anywhere appearing user B, To resolve 1) Adapting of the current implementation when cloning issues: To resolve 2) Maybe we should not copy the history from issue # 1 to # 2 | ||||
Tags | No tags attached. | ||||
In my opinion, the behavior of the "copy" function from the view issues should generally match that of a "regular" issue clone. At the moment, Mantis is not consistent: code for cloning in bug_report.php is not the same as that for copy which is handled by bug_copy() function in bug api. The same code should be used for both. I also believe that it makes no sense to duplicate the history, considering that the notes ID references are wrong. |
|
That was serious security breach for me, because users can "Copy" issues without being spotted. To resolve it add: history_log_event_special( $t_new_bug_id, BUG_CREATED_FROM, '', $t_bug_id ); to the end of bug_copy() function in bug_api.php ( just before return $t_new_bug_id;) Copied issues will get "Issue generated from" history note. |
|
Patch committed. See below for illustration of changes
|
|
After applying the patch there is still a difference Cloning an issue using view.php creates two entries in history.
Copying an issue using view_all_bug_page.php creates just
|
|
Adding the "New Issue" history item is easy to fix*, but it's only the tip of the iceberg. The problem I referred to in 0013816:0031076, is that the Clone operation is interactive, and offers option to the user to decide whether they want or not to
On the other end, the Copy function does not allow users to pick what to clone, it does everything i.e.
And finally the copy does not allow to create a relationship with the original bug.
|
|
A CVE identifier has been assigned to this issue: CVE-2012-1119 MantisBT 1.2.8 13816 copy/clone bug report action failed |
|
Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch |
|
MantisBT: master cf5df427 2012-03-01 08:58 Details Diff |
Fix 0013816: Update history when copying issues Until now, copying bugs using the "View Issues" page creates wrong/ incomplete history (entries for notes reflect the id's of the original issue's notes) and also does not record any trace that the new issue is in fact clone of another, which can be a source of confusion. This commit prevents the duplication of the original bug's history, generating instead a single history entry similar to what happens when cloning a bug with the Clone button in view.php page. The display of history entries for cloned bugs has been slightly modified, the bug id is now printed under the 'Field' column instead of the 'Change' column, like entries for adding notes (as cloning s not a change). |
Affected Issues 0013816 |
|
mod - bug_actiongroup.php | Diff File | ||
mod - core/bug_api.php | Diff File | ||
mod - core/history_api.php | Diff File | ||
MantisBT: master-1.2.x dd634e7c 2012-03-01 08:58 Details Diff |
Fix 0013816: Update history when copying issues Until now, copying bugs using the "View Issues" page creates wrong/ incomplete history (entries for notes reflect the id's of the original issue's notes) and also does not record any trace that the new issue is in fact clone of another, which can be a source of confusion. This commit prevents the duplication of the original bug's history, generating instead a single history entry similar to what happens when cloning a bug with the Clone button in view.php page. The display of history entries for cloned bugs has been slightly modified, the bug id is now printed under the 'Field' column instead of the 'Change' column, like entries for adding notes (as cloning s not a change). |
Affected Issues 0013816 |
|
mod - bug_actiongroup.php | Diff File | ||
mod - core/bug_api.php | Diff File | ||
mod - core/history_api.php | Diff File | ||
MantisBT: master dea7e315 2012-03-02 02:28 Details Diff |
Add "New Issue" entry to history when copying bugs When bug_copy() is called with p_copy_history=false, a 'NEW_BUG' history entry is added to ensure consistency of behavior with Clone button. Fixes 0013816 |
Affected Issues 0013816 |
|
mod - core/bug_api.php | Diff File | ||
MantisBT: master-1.2.x 38e23e3b 2012-03-02 02:28 Details Diff |
Add "New Issue" entry to history when copying bugs When bug_copy() is called with p_copy_history=false, a 'NEW_BUG' history entry is added to ensure consistency of behavior with Clone button. Fixes 0013816 |
Affected Issues 0013816 |
|
mod - core/bug_api.php | Diff File |