Saving as draft overwrites previous version

[abaco]

Bug Report

Saving a document as draft overwrites the previous version in some cases.

Expected Behavior

The previous versions are always preserved.

Current Behavior

The latest version is overwritten by the new content.

Steps to Reproduce

Please see my fork for reproductions.

[jmikrut]

Hey @abaco — thank you for bringing this up!

So, if you have autosave enabled, we only keep ONE autosaved version because otherwise your versions would become obliterated with thousands of autosaved versions as you edit a document. They autosave quite often, and you will end up with a ton of unnecessary autosaved versions. So, with autosave enabled, we only update the existing autosaved document rather than create a new one each time.

If you do not have autosave enabled, and only have drafts enabled, we create a new draft version each time a draft is saved as you are expecting.

However, we do see the value in potentially adding a feature to always create new autosave drafts even with autosave enabled. This wouldn't be too hard to do, but it would be a new feature.

What do you think? Given the above, I will convert this to a Discussion for now, and then if we all mutually decide that it is worthwhile to add to the core, we'll get it done!

[abaco]

Thank you @jmikrut, what you describe makes totally sense. However there are still a couple of little things that seem off to me.

I started looking into this because the server errors out whenever I save a draft on top of a published version. In this case a published document had title: "t2" and I updated it to "t3". I got this error:

[07:21:44] ERROR (payload): There was an error while saving a version for the Job Offer with ID 63202f78a0b2432c005e52e5.
[07:21:44] ERROR (payload): _job-offers_versions validation failed: version.title: Cast to Embedded failed for value "t2" (type string) at path "title" because of "ObjectExpectedError"
    ValidationError: _job-offers_versions validation failed: version.title: Cast to Embedded failed for value "t2" (type string) at path "title" because of "ObjectExpectedError"
        at model.Document.invalidate (/Users/..../payload/node_modules/mongoose/lib/document.js:3050:32)
        at SingleNested.Subdocument.invalidate (/Users/..../payload/node_modules/mongoose/lib/types/subdocument.js:213:12)
        at SingleNested.$set (/Users/..../payload/node_modules/mongoose/lib/document.js:1412:12)
        at SingleNested.$set (/Users/..../payload/node_modules/mongoose/lib/document.js:1089:16)
        at SingleNested.Document (/Users/..../payload/node_modules/mongoose/lib/document.js:166:12)
        at SingleNested.Subdocument (/Users/..../payload/node_modules/mongoose/lib/types/subdocument.js:31:12)
        at new SingleNested (/Users/..../payload/node_modules/mongoose/lib/schema/SubdocumentPath.js:71:17)
        at SubdocumentPath.cast (/Users/..../payload/node_modules/mongoose/lib/schema/SubdocumentPath.js:179:12)
        at SubdocumentPath.SchemaType.applySetters (/Users/..../payload/node_modules/mongoose/lib/schematype.js:1192:12)
        at model.$set (/Users/..../payload/node_modules/mongoose/lib/document.js:1364:22)

This is alarming enough. The error says that a version of the published document, with title: "t2", could not be saved. Indeed there's no saved version with title: "t2", but there's a version for the current draft with title: "t3". This made me believe I found a bug.

However, reverting to the published version works fine. This is confusing IMO, it's a UX issue. I'd like to be able to use the versions UI to compare the current draft to the previous published versions, including the currently published version, and revert to that from there. Instead the current published version seems to be gone, and the latest saved version is identical to the current draft, which is useless.

To be clear, the data is there and I can revert to previous versions, it's just confusing.

[abaco]

I'm still poking around and I think there's something wrong with how versions are saved.

Consider a collection with drafts enabled, no autosave. The following happens (on version 1.1.0):

1. Set title to "t1", save as draft. No version is saved.
2. Set title to "t2", save as draft. One version with "t2" is saved.
3. Set title to "t3", save as draft. Two versions are available: with "t2" and "t3".

Note that by version I mean what is returned by findVersions.

That looks inconsistent to me. Why is the first draft dropped? Why is a version saved for each subsequent draft, at the moment of saving that same draft (thus duplicating the data)?

[abaco]

Back to the question of whether to save every draft, even with autosave enabled, I think it would be very useful to have fine-grained control on what to save and how long to keep it. A few examples of what I have in mind:

• Save every published version forever
• Don't save any version of drafts
• Save a version of a draft only if the update happens after longer than the autosave interval (effectively filters out autosaved versions)
• Save a separate version of a draft for each user
• Store the latest 20 versions of a draft
• Store every published version for one year

And so on. This would required a gazillion configuration parameters! But then I realized such logic can be implemented in afterChange hooks. One can always query the saved versions and decide what to delete. What do you think?

This of course is only possible is there's a way to save all the versions to begin with. So I think it would be good to allow every draft version to be saved.

[geb-medicuja]

For our editorial workflow we need to have explicit saved drafts to pass from one person to another, as well as for an editor to view/revert to a previous known good draft state if for example some items were deleted by accident.
We would therefore like to have a save button as well as the publish button along with the autosave so that autosaves are saved to the last draft version but the editor can also 'save a version' as a new draft version.

It would be great if we could also add a name/comment to the save so that it is easy to identify the most appropriate draft version to look at. See attached screenshots of similar features in Google Sheets and Figma: