View Issue Details

IDProjectCategoryView StatusLast Update
0013816mantisbtsecuritypublic2014-09-23 18:05
ReporteratrolAssigned 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

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 
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

View 2 revisions

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 13:58:00

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).
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 13:58:00

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).
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 07:28:33

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
mod - core/bug_api.php Diff File

MantisBT: master-1.2.x 38e23e3b

2012-03-02 07:28:33

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
mod - core/bug_api.php Diff File

Issue History

Date Modified Username Field Change
2012-01-29 10:56 atrol New Issue
2012-01-29 10:57 atrol Description Updated View Revisions
2012-01-29 16:19 dregad Note Added: 0031076
2012-02-25 03:29 noizeg Note Added: 0031319
2012-03-01 04:38 dregad Relationship added related to 0004200
2012-03-01 04:41 dregad Assigned To => dregad
2012-03-01 04:41 dregad Status new => assigned
2012-03-01 04:41 dregad Target Version => 1.2.9
2012-03-01 18:18 dregad Note Added: 0031363
2012-03-01 18:18 dregad Status assigned => resolved
2012-03-01 18:18 dregad Fixed in Version => 1.2.9
2012-03-01 18:18 dregad Resolution open => fixed
2012-03-01 19:00 dregad Changeset attached => MantisBT master cf5df427
2012-03-01 19:00 dregad Changeset attached => MantisBT master-1.2.x dd634e7c
2012-03-02 03:17 atrol Note Added: 0031366
2012-03-02 10:19 dregad Note Added: 0031367
2012-03-02 10:39 dregad Note Edited: 0031367 View Revisions
2012-03-02 11:00 dregad Changeset attached => MantisBT master dea7e315
2012-03-02 11:00 dregad Changeset attached => MantisBT master-1.2.x 38e23e3b
2012-03-03 21:45 vboctor Status resolved => closed
2012-03-06 17:34 dhx Note Added: 0031393
2013-04-05 17:57 grangeway Status closed => acknowledged
2013-04-05 17:57 grangeway Note Added: 0036309
2013-04-05 18:24 grangeway Relationship added related to 0015721
2013-04-06 03:42 dregad Status acknowledged => closed
2013-04-06 07:23 grangeway Status closed => acknowledged
2013-04-06 09:22 dregad Tag Attached: 2.0.x check
2013-04-06 09:23 dregad Status acknowledged => closed
2014-09-23 18:05 grangeway Tag Detached: 2.0.x check