Adding a "change log" for lists that records the version history of items

[molomby]

Functionality by which all changes to items are logged. This would probably be configured on a list level.

Outstanding questions include:

• Do we log complete records or deltas?
• Are ""historical"" or non-current versions stored in..
  • the same collection/table (eg. a with an ""isCurrent"" flag)
  • a shadow copy of the collection/table
  • some other way, like subdocuments in an array
• How many versions should be kept and for how long?
• What's the cleanup/purge process for old/redundant versions? (A worker or enforce for each write?)
• How visible/transparent should versions be?
  • Are previous version visible through the admin UI (or just logged for analysis)
  • Can users "rollback" to an item version?
  • Can previous version be queried via GraphQL?
• How does this interact with publishing workflows?
  • Is it possible to create new version of an item but use an older version operationally? Eg. a draft -vs- published version of content
• How does this interact with multi-language support? Do historical versions "cut across" language versions or vice versa?
• Operationally, how to previous version interact with migrations?

Some of these questions need to be answered to design the common Keystone components (such as the Admin UI), others will end up being adapter-specific.

"We" have build functionality like this before (Bluetree had versioned tables). More recently, Hotel101 implemented similar functionality in userland (for rate cards); we add multiple records to a table that span a single "lineage" ID.

[JedWatson]

Keystone 4 had a feature that implemented this as well, using a second collection. It stored the diff of changes with each save to a document. It was never surfaced in the Admin UI, but you could enable it with the history option.

Implementation here: https://github.com/keystonejs/keystone/blob/master/lib/schemaPlugins/history.js

[stale[bot]]

It looks like you haven't had a response in over 3 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contributions. :)

[stale[bot]]

It looks like there hasn't been any activity here in over 6 months. Sorry about that! We've flagged this issue for special attention. It wil be manually reviewed by maintainers, not automatically closed. If you have any additional information please leave us a comment. It really helps! Thank you for you contribution. :)

[MadeByMike]

We've got hooks as as well as the updatedAt/updatedBy list plugins.

This is probably more about having an option to turn delete into a "soft delete" where every version update to an item is a new version and the previous is soft deleted. - Probably a good idea.

[charkour]

Although this issue was closed, this feature does not exist, correct?

Is there a way to do this with Keystone 6?

Thank you.

[dcousens]

Hi @charkour, you are correct that this is not actively a feature in keystone-6, you can somewhat track the feature request using https://github.com/keystonejs/keystone/discussions/5998 if that fits for you.

I might lock this thread, it's somewhat misleading as none of the responses are relevant to keystone-6 as it stands today.