Broken issue edit history #14512

New Issue

2025-11-02T11:14:59-06:00

GiteaMirror commented

2025-11-02 11:14:59 -06:00

Originally created by @didim99 on GitHub (May 21, 2025).

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

Originally created by @didim99 on GitHub (May 21, 2025). ### 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

GiteaMirror added the topic/issues issue/not-a-bug labels 2025-11-02 11:14:59 -06:00

GiteaMirror commented

2025-11-02 11:15:00 -06:00

@wxiaoguang commented on GitHub (May 22, 2025):

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

@wxiaoguang commented on GitHub (May 22, 2025): It was not designed to be used for "audit" purpose. ![Image](https://github.com/user-attachments/assets/fc54e644-810e-41ed-a247-9384b1ca9786)

GiteaMirror commented

2025-11-02 11:15:00 -06:00

@didim99 commented on GitHub (May 22, 2025):

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.

@didim99 commented on GitHub (May 22, 2025): > 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](https://github.com/go-gitea/gitea/blob/0d1d57c5bf17b364d9528bc58f578b6f72aa41ba/models/issues/content_history.go#L89) if a previous edit poster differ from current, mark next edit as multi-user. It seems to be not wery hard to implement.

GiteaMirror commented

2025-11-02 11:15:00 -06:00

@RiverIntheSky commented on GitHub (Jun 19, 2025):

I’m fine with deleting old revisions, but merging edits from different users is absolutely confusing, I think this as a bug, only revisions by the same user should be merged.

@RiverIntheSky commented on GitHub (Jun 19, 2025): I’m fine with deleting old revisions, but merging edits from different users is absolutely confusing, I think this as a bug, only revisions by the same user should be merged.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14512