Broken issue edit history

[didim99]

Description

If you have an issue that edited many times by multiple users (including setting/removing checkboxes) in some situations different edits in edit history becomes merged in one single edit, even if that made by different users. It seems to be a critical issue in case of audit, because you can't properly determine authorship of that changes.

At the moment I can't describe a full chain of steps to reproduce this behaviour, but in our instance (about 200 repos and 20 active users) I encountered this several time over the last year (for issues that has been edited more than 10 times by multiple users). There is approximate event sequence:

• User A creates issue with the list of 4 checkboxes
• User A edits issue content (1), e.g. adds a new item to the end of list
• User B edits issue content (2), e.g. sets a checkbox number 2
• User C edits issue content (3), e.g. sets a checkbox number 3

  At this moment issue edit history correct

• User A edits issue content (4) e.g. edits a first list item
• User B edits issue content (5), e.g. removes a checkbox number 2

  At this moment issue edit history shows (3) and (4) as single edit posted by user A.
  In fact, user A did not touch checkbox number 3

I checked the DB table issue_comment_history and see that the content of table same as shown in UI. Thus it is not a visualization bug but actually corrupted data.

Gitea Version

1.23.7

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

Not matters

Operating System

Ubuntu Server 20.04

How are you running Gitea?

Bare metal (official install script)

Database

MySQL/MariaDB

[wxiaoguang]

It was not designed to be used for "audit" purpose.

[didim99]

It was not designed to be used for "audit" purpose.

This behaviour should be documented to avoid confusing users.

Maybe you can mark edits as "merged"/"multi-user" in KeepLimitedContentHistory? We can query a poster ID and check here if a previous edit poster differ from current, mark next edit as multi-user. It seems to be not wery hard to implement.