MantisBT

View Issue Details Jump to Notes ] Wiki ] Related Changesets ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013816mantisbtsecuritypublic2012-01-29 10:562013-04-06 09:23
Reporteratrol 
Assigned Todregad 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version1.2.8 
Target Version1.2.9Fixed in Version1.2.9 
Summary0013816: Enhance history when copying issues
DescriptionCoying 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
Tags2.0.x check
Attached Files

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

-  Notes
User avatar (0031076)
dregad (developer)
2012-01-29 16:19

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.
User avatar (0031319)
noizeg (reporter)
2012-02-25 03:29

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.
User avatar (0031363)
dregad (developer)
2012-03-01 18:18

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 
User avatar (0031366)
atrol (developer)
2012-03-02 03:17

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>
User avatar (0031367)
dregad (developer)
2012-03-02 10:19
edited on: 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.

User avatar (0031393)
dhx (developer)
2012-03-06 17:34

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
User avatar (0036309)
grangeway (developer)
2013-04-05 17:57

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

- Related Changesets
MantisBT: master cf5df427
Timestamp: 2012-03-01 13:58:00
Author: 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
Timestamp: 2012-03-01 13:58:00
Author: 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
Timestamp: 2012-03-02 07:28:33
Author: 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
Timestamp: 2012-03-02 07:28:33
Author: 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


MantisBT 1.2.17 [^]
Copyright © 2000 - 2014 MantisBT Team
Time: 0.0894 seconds.
memory usage: 3,113 KB
Powered by Mantis Bugtracker