View Issue Details

IDProjectCategoryView StatusLast Update
0025792mantisbtbugtrackerpublic2020-05-11 11:33
ReporterAnsgar Arbeiter Assigned To 
PrioritynormalSeveritytweakReproducibilityalways
Status newResolutionopen 
Product Version2.20.0 
Summary0025792: in cloned issue the order of comments and pictures is not kept
Description

in clone, the pictures are first, then the comments

TagsNo tags attached.
Attached Files
ClonedPictureOrder.png (217,646 bytes)   
ClonedPictureOrder.png (217,646 bytes)   

Relationships

related to 0023195 new Clone Issue modifies notes modified date in history 

Activities

Ansgar Arbeiter

Ansgar Arbeiter

2019-05-29 08:49

reporter   ~0062158

suggestion (if not wanted to keep the original timestamps):
use time of cloning as start time and for each picture or comment increase one second.
then the order is kept (without any extra handling) and there are no dates from the past.
(regarding 0023195)

dregad

dregad

2019-05-29 12:13

developer   ~0062164

Last edited: 2019-05-29 12:13

Keeping the original timestamps means that you would have bugnotes / attachments (hereafter: activities) that are older than the bug itself... That would be weird.

Your suggestion to bump the time +1s for each activity causes problems as well :

  1. Currently, attachments are linked to the bug itself, not to a bugnote (see 0021733); we just display them inline with the bugnotes for convenience, based on the file's timestamp (that's done by Activity API). Since they are handled differently within MantisBT core, there are two distinct processes to copy them (look at IssueAddCommand.php, around line 380). I guess we could rely on Activity API (used to display bugnotes in the correct order on bug view page) to refactor this code per your suggestion, but see point 2
  2. It implies that activities would be created with a timestamp in the future, which could result in a situation where a bugnote added shortly after the issue has been cloned, could appear in the middle of the cloned activities (this risk increases with the number of activities the master issue has)
Ansgar Arbeiter

Ansgar Arbeiter

2019-05-29 12:36

reporter   ~0062165

Last edited: 2019-05-29 12:38

bugnote added shortly after the issue has been cloned

that is correct but probably not the normal situation. if i have 20 comments and attachments, then i have to add new comments or attachments within 20 seconds after cloning to break the order.
(i personally first remove now unused comments and attachments in cloned issue first, before adding new)

one modification could be to have the clone timestamp as start time and go backward. go from last item to first and for each decrement one second.
(it will lead to item times before clone time, but i think the user can bring this little time range together in mind)

my suggestion was meant to have little effort to solve the problem.

if you want to make it proper then i would add an order index per attachment (would also offer to change the comment order after adding, the date can still be present)
or assign a comment ID also to attachments and then sort by date + comment ID (if dates are same, use ID).

mahindra

mahindra

2020-04-27 03:58

reporter   ~0063919

Last edited: 2020-04-28 05:57

It is not enough to add the seconds based on the order and write them in the change references copied from the old ticket.

The reason is that the copied notes were written by other users before the new ticket was copied, cloned or so on.
Therefore, it is OK if the note date is before the new ticket, because it is from an older one!!!

The change history should include a note copied from ID-old and the author (copier) of the new ticket.

So everyone knows their way around.

mahindra

mahindra

2020-04-28 06:03

reporter   ~0063926

@dregad - Best procedure inserted above - the author and the date of entry of the note or attachment must not be lost.
"The copyright is at the time before the new ticket" - that's OK only in this case this case if the issue history shows the Copy from ID and URL.

mahindra

mahindra

2020-05-11 11:33

reporter   ~0063969

If you copy an ID with Checkbox in view_all_bug_page.php - the timestamps are correct.
So please realize the same in the clone issue function.