View Issue Details

IDProjectCategoryView StatusLast Update
0013816mantisbtsecuritypublic2014-09-23 18:05
Reporteratrol Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.8 
Target Version1.2.9Fixed in Version1.2.9 
Summary0013816: Enhance history when copying issues
Description

Coying issues using the "View Issues" page creates wrong/incomplete history

Example:
User A reports issue # 1, and adds note ~ 1
You get history entries "New issue" and "Note Added: 1"

User B copies the issue using the "Copy" operation of the "View Issues" page.
You get issue # 2 and note ~ 2
and you get a 1:1 copy of the history entries from # 1 "New issue" and "Note Added: 1"

1) you don't see anywhere appearing user B,
2) you see note ~ 2 in issue # 2 but history entry "Note Added: 1"

To resolve 1) Adapting of the current implementation when cloning issues:
The clone get's "Issue generated from", the original gets "Issue cloned".

To resolve 2) Maybe we should not copy the history from issue # 1 to # 2

TagsNo tags attached.

Relationships

related to 0004200 closedmasc Create Child should use Report Page 
related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

dregad

dregad

2012-01-29 16:19

developer   ~0031076

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.

noizeg

noizeg

2012-02-25 03:29

reporter   ~0031319

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 );
history_log_event_special( $t_bug_id, BUG_CLONED_TO, '', $t_new_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.

dregad

dregad

2012-03-01 18:18

developer   ~0031363

Patch committed.

See below for illustration of changes
<pre>
Clone button (baseline)

Original issue
2012-03-01 22:47 Administrator Note Added: 0000027
2011-12-14 16:50 Administrator New Issue

New issue via Clone button (116):
2012-03-01 23:10 Test Administrator Issue generated from 0000093
2012-03-01 23:10 Test Administrator New Issue

Original issue after clone operation
2012-03-01 23:10 Test Administrator Issue cloned 0000116
2012-03-01 22:47 Administrator Note Added: 0000027
2011-12-14 16:50 Administrator New Issue

Copy from view issues (original)

Original issue
2012-03-01 23:09 Test Administrator Note Added: 0000031
2012-01-05 16:36 Test Administrator New Issue

New issue via Copy (117) - NOTE: the actual note's ID is 32 !
2012-03-01 23:09 Test Administrator Note Added: 0000031
2012-01-05 16:36 Test Administrator New Issue

Original issue after copy operation - NOTE: no change, can't tell it's a copy !
2012-03-01 23:09 Test Administrator Note Added: 0000031
2012-01-05 16:36 Test Administrator New Issue

Copy from view issues (new version)

Original issue
2012-03-01 23:24 Test Administrator Note Added: 0000035
2012-03-01 23:23 Test Administrator New Issue

New issue via Copy - NOTE: history not copied anymore
2012-03-01 23:26 Test Administrator Issue generated from: 0000122

Original issue after copy operation
2012-03-01 23:26 Test Administrator Issue cloned: 0000123
2012-03-01 23:24 Test Administrator Note Added: 0000035
2012-03-01 23:24 Test Administrator New Issue
</pre>

atrol

atrol

2012-03-02 03:17

developer   ~0031366

0013816:0031076

In my opinion, the behavior of the "copy" function from the view issues should generally match that of a "regular" issue clone.

After applying the patch there is still a difference

Cloning an issue using view.php creates two entries in history.

  1. New Issue
  2. Issue generated from: <bug_id>

Copying an issue using view_all_bug_page.php creates just

  1. Issue generated from: <bug_id>
dregad

dregad

2012-03-02 10:19

developer   ~0031367

Last edited: 2012-03-02 10:39

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

  • copy bug notes
  • copy attachments
  • set relationship to original bug

On the other end, the Copy function does not allow users to pick what to clone, it does everything i.e.

  • bug notes
  • attachements
  • relationships
  • monitoring users
    (not the history anymore, since commit below)

And finally the copy does not allow to create a relationship with the original bug.

  • EDIT: it's done, actually. Changeset should be attached shortly.
dhx

dhx

2012-03-06 17:34

reporter   ~0031393

A CVE identifier has been assigned to this issue:

CVE-2012-1119 MantisBT 1.2.8 13816 copy/clone bug report action failed
to leave an audit trail

grangeway

grangeway

2013-04-05 17:57

reporter   ~0036309

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master cf5df427

2012-03-01 08:58

dregad


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

dregad


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

dregad


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

dregad


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