Enforce validation on drafts?

[shell dock]

Currently, you can save a draft regardless of validation rules (required, unique, custom validations, etc).
How would you go about enforcing the same validation we have for "Publish" on "Save"?

(this would probably become a moot point once https://github.com/payloadcms/payload/discussions/1324 is implemented, but I'm wondering if there might be a somewhat straightforward solve in the meantime 🤔)

[shell dock]

Hmmm, so after doing some more digging, looks like the Form component has a skipValidation option that get set to true in the various operations (create, update, etc) when it's a draft (eg: https://github.com/payloadcms/payload/blob/4d578f1bfd05efab5cc8db95895eabb776b2d9d1/src/collections/operations/update.ts#L225 ).

I feel like an additional parameter in the CollectionConfig could be nice, something like this:

  drafts: true,
  skipDraftsValidation: false, // defaults to `true`
}```

This wouldn't be compatible with the autosave feature though, so that's probably not PR worthy as is...  
Is there any other side effect to adding validation on drafts that I'm not thinking about? 🤔 

If you have it, I'd very much appreciate any insights, tips, or hints as to how I could go about actually implementing something to get validation on drafts. 👀 🙏

---

For full context, what I'm trying to achieve here is being able to validate my fields without relying on the "Publish" process. This is for my "translation provider" plugin so that I can make sure that fields are valid before sending them to be translated, and I need to be able to do this while the doc is still a draft.

So maybe instead of trying to "add validation on drafts", I should be trying to "trigger validation manually"... 🤔

[compact gust]

You could add a UI field in the top of the sidebar that shows the validation status even for drafts. That could be useful to your editing experience.

Is there any other side effect to adding validation on drafts that I'm not thinking about? 🤔

The reason we don't validate when saving drafts is purely a UX decision. When working on a document, you may just want to save your progress and ignore required fields and other validation rules that impede you from doing so.
There will be more work going into publishing workflows in the future which could mean that there are additional statuses or these become more extensible. Currently there is only status: 'draft' | 'published'. It would be nice to have customized control over the status to add review steps or scheduled for publish and whatnot. For those in-between steps, validation would be necessary.

You have my brain-wheels turning, so far we left versions pretty open ended, but I think some more fine-tuning and customization of the versions is needed.

[shell dock]

The reason we don't validate when saving drafts is purely a UX decision. When working on a document, you may just want to save your progress and ignore required fields and other validation rules that impede you from doing so.

Yup that makes total sense, and I would rather keep it that way as well if possible. And especially once you add the "autosave" feature into the mix, not validating content basically goes from "nice-to-have" to "mandatory".

There will be more work going into publishing workflows in the future which could mean that there are additional statuses or these become more extensible. Currently there is only status: 'draft' | 'published'. It would be nice to have customized control over the status to add review steps or scheduled for publish and whatnot.

That's exactly what I'm looking for ( 🙌 ) and trying to work around in the meantime.

For context, we need to translate all of our content through a third party system and professional translators. This needs to happen ahead of "publish" (we don't want any non-translated content to be live, and need to be able to edit and translated already live content), but we also want to make sure the content we're sending for translation is valid (going through several days of paid translation only to come back, hit "Publish", and realize some content is invalid would be pretty bad).

This leaves me with two options for now (as far as I can see):

1. Validate content somehow ahead of "publish", either by
   a. Forcing validation on draft save
   b. Manually trigger the validation without relying on the "save" or "publish" buttons
2. or don't rely on the "publish" system to actually publish content in the front end but add a new "isLive" field or something to control this instead

I'd really rather not do 2. as there's a lot of nice QoL stuff that's built in with the draft system and how published docs behave and all that that I'd rather not lose or have to rebuild. Which leaves me with 1a or 1b while we wait for that future work on publishing workflow. 😄

You could add a UI field in the top of the sidebar that shows the validation status even for drafts.

It sounds like this would basically be 1b, right? Do you have any thoughts or pointers on where I should start looking for implementing something like this (ie: manually triggering the validation)? 👀

[shell dock]

Oh, while doing something totally unrelated, I came across the useForm hook and its validateForm function!
This is great and allows me to check whether the content is valid or not, but this doesn't give me or the user any info as to where the errors are.

I'll continue to investigate, but if anyone knows how to display the same error-handling UI than when using the "Publish" button (cf screenshot), I'd be very grateful! 🙏

[rain seal]

The main issue you will run into here is that the concept of a "draft" is that it is unfinished and can be picked up again later.

By enforcing validation you are forcing the user to finish the content item completely before they can save the draft, in which case they might as well just publish it.