AppFlowy-IO/AppFlowy

Fork 0

mirror of https://github.com/AppFlowy-IO/AppFlowy.git synced 2026-03-24 04:46:56 +00:00

[GH-ISSUE #3064] [FR] Edit history #1349

New issue

Open

opened 2026-03-23 20:48:11 +00:00 by mirror · 3 comments

mirror commented

2026-03-23 20:48:11 +00:00

Owner

Originally created by @emmggi on GitHub (Jul 26, 2023).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/3064

Originally assigned to: @appflowy on GitHub.

Description

I suggest document work space to have edit history. It should keep track of changes we do in our documents. This would make most sense for the document work space. I don't see this being useful for calendar, grid or kanban.

Most important use case for this is when a user deletes a piece of information that will be important in the future.

Impact

All users.

Additional Context

Should have a list of edits in a dialog/side bar.
Title of the list item should have its date and time. Subtitle could have how many blocks were changed or how many characters are different.
Clicking on an edit should show difference side by side or inline, between state of the current document and the edit we clicked on.
We should be able to search history for keywords.

I suggest making the data for edits compact. Maybe just persist blocks that were changed in the database, not to create huge DB files, but I'll leave this to the more knowledgeable.

Originally created by @emmggi on GitHub (Jul 26, 2023). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/3064 Originally assigned to: @appflowy on GitHub. ### Description I suggest document work space to have edit history. It should keep track of changes we do in our documents. This would make most sense for the document work space. I don't see this being useful for calendar, grid or kanban. Most important use case for this is when a user deletes a piece of information that will be important in the future. ### Impact All users. ### Additional Context 1. Should have a list of edits in a dialog/side bar. 2. Title of the list item should have its date and time. Subtitle could have how many blocks were changed or how many characters are different. 3. Clicking on an edit should show difference side by side or inline, between state of the current document and the edit we clicked on. 4. We should be able to search history for keywords. I suggest making the data for edits compact. Maybe just persist blocks that were changed in the database, not to create huge DB files, but I'll leave this to the more knowledgeable.

mirror added the

labels

2026-03-23 20:48:11 +00:00

mirror commented

2026-03-23 20:48:12 +00:00

Author

Owner

@lalomartins commented on GitHub (Jun 30, 2024):

To add my 2¥ to an issue that for me is a dealbreaker:

A risk is that storing every revision ever might bloat the storage needs and get unwieldy over time. The most common fix for that is to simply limit the retention, but that then makes the feature no longer suit all use cases; for design documents, for example, it's important to have a history going back to the first draft so we can trace how the design evolved.

What I find the best solution is to have a retention window (maybe a week) within which we keep all revisions, and then when passing that, keeping only key revisions.

The two ways I know about for deciding what is a key revision are:

Explicit, or named revisions, or commits. Google Docs does this. Someone can manually go in the history and tag a revision with a name so it won't get deleted.
Automatic, session-based. If the time between revision A and the next one B is more than a certain limit, say 6 hours, then A gets saved permanently.

With a session-based approach, there could even be 2 layers of retention. For example, once per day we could remove revisions more than a day older, where there is a newer revision less than 30 minutes later; and then once a month we could do the same but with a window of 12 hours.

For maximum flexibility, both approaches could be combined too, at the cost of bloating the UX. That is, revisions to preserve are picked automatically, but explicitly named revisions are taken out of the algorithm entirely and never removed.

Okay, that may have ended up being 4 or 5¥ 😹 I hope it's useful.

@lalomartins commented on GitHub (Jun 30, 2024): To add my 2¥ to an issue that for me is a dealbreaker: A risk is that storing every revision ever might bloat the storage needs and get unwieldy over time. The most common fix for that is to simply limit the retention, but that then makes the feature no longer suit all use cases; for design documents, for example, it's important to have a history going back to the first draft so we can trace how the design evolved. What I find the best solution is to have a retention window (maybe a week) within which we keep all revisions, and then when passing that, keeping only key revisions. The two ways I know about for deciding what is a key revision are: - Explicit, or named revisions, or commits. Google Docs does this. Someone can manually go in the history and tag a revision with a name so it won't get deleted. - Automatic, session-based. If the time between revision A and the next one B is more than a certain limit, say 6 hours, then A gets saved permanently. With a session-based approach, there could even be 2 layers of retention. For example, once per day we could remove revisions more than a day older, where there is a newer revision less than 30 minutes later; and then once a month we could do the same but with a window of 12 hours. For maximum flexibility, both approaches could be combined too, at the cost of bloating the UX. That is, revisions to preserve are picked automatically, but explicitly named revisions are taken out of the algorithm entirely and never removed. Okay, that may have ended up being 4 or 5¥ 😹 I hope it's useful.

mirror commented

2026-03-23 20:48:12 +00:00

Author

Owner

@EPGames commented on GitHub (May 14, 2025):

This is pretty much needed to be usable in non-personal environment. Is there any new info on the progress? Thanks!

@EPGames commented on GitHub (May 14, 2025): This is pretty much needed to be usable in non-personal environment. Is there any new info on the progress? Thanks!

mirror commented

2026-03-23 20:48:12 +00:00

Author

Owner

@pascalpvk commented on GitHub (Jun 2, 2025):

Sources of inspiration for the design :

Code in Git
Google Docs
ClickUp Documents

One store only modifications (with time stamp and editor ID), not full versions of document.

@pascalpvk commented on GitHub (Jun 2, 2025): Sources of inspiration for the design : - Code in Git - Google Docs - ClickUp Documents One store only modifications (with time stamp and editor ID), not full versions of document.

mirror referenced this issue

2026-03-23 21:38:53 +00:00

[PR #1357] [MERGED] Update README.md #4681

mirror referenced this issue

2026-03-23 22:15:21 +00:00

[PR #1360] [MERGED] Update README.md #4683