Required option on fields is not working at all

[simonwidjaja]

System Information

• v3.2.4:
• mongodb:

---

Are there any known issues with the “required” option on field level?
I have a pretty basic and flat model (no components/relations etc). I have set several fields to “required” via UI, but it doesn’t seem to have any effect. I can still create new fully blank documents without entering ANY data into any fields. The result is a blank document that fully ignored all the “required” flags…
I have tried to drop the collection completely on mongo atlas, so it will be recreated. The result was, that “unique” fields were added to the collection index. But the “required” option is still not working at all…

Known issue or am I doing something wrong?

Any hint appreciated…

[sunnyson]

Can you try to delete .cache and build folders and run yarn build again

[simonwidjaja]

still the same behavior.

rm -R .cache
rm -R build

I tried all:
develop --watch-admin, build, start

I can still create blank documents with required fields being empty…

Any other ideas?

[sunnyson]

How exactly did you create them?
Strapi UI, API/services, query, ORM?

[simonwidjaja]

All via UI
(created collection via Content-Types-Builder UI, and creating empty document also via Content Manager UI).

[sunnyson]

Can you please share the {model}.settings.json file?

[sunnyson]

Strange thing, when I try to create a New entry the validation doesn’t allow me to create it without the required field. But if I modify an existing document then it allows me to save it without any value.

Also, I see that description says about “create”, and nothing about “update”. @DMehaffy ?

[simonwidjaja]

sure

{
  "kind": "collectionType",
  "collectionName": "newsletters",
  "info": {
    "name": "Newsletter",
    "description": ""
  },
  "options": {
    "increments": true,
    "timestamps": true,
    "draftAndPublish": true
  },
  "attributes": {
    "InternalTitle": {
      "type": "string",
      "unique": true,
      "required": true
    },
    "Image1": {
      "model": "file",
      "via": "related",
      "allowedTypes": [
        "images"
      ],
      "plugin": "upload",
      "required": false
    },
    "Image2": {
      "model": "file",
      "via": "related",
      "allowedTypes": [
        "images"
      ],
      "plugin": "upload",
      "required": false
    },
    "Data": {
      "type": "json"
    },
    "Tags": {
      "type": "string"
    },
    "pool": {
      "type": "enumeration",
      "enum": [
        "aaa",
        "bbb"
      ],
      "required": true
    },
    "subject": {
      "type": "string",
      "required": true,
      "minLength": 100
    }
  }
}

So InternalTitle, pool, subject are all required.

[simonwidjaja]

interesting. in my case validation is not working even when creating a new document via UI.

A better description would be:

“You won’t be able to save a document if this field is empty”

[sunnyson]

Verified your model, so the thing is that you are using the Draft/Publish feature, which allows you to save a Draft without required fields. But when you are trying to publish them then it will throw an error because you don’t have all the required fields.

[sunnyson]

Disabled draft/publish:

[simonwidjaja]

ahhh ok. that is definitely unexpected. I would expect that the validation is already active for draft documents.

is there a reason for deactivating validation on drafts?

[sunnyson]

Yes, because it’s draft

Let’s say in your case with newsletters you have a content writer who writes only the title, subject, body of that newsletter. Imagine that your newsletter has 20 fields, would you let it configure all these required Fields? No.

Also in Enterprise edition you can disallow some fields for admin users based on roles. So in that case you can hide other fields that should be configured only by “managers” and provide access only to fields like “title, subject, body” to the content writer.

[DMehaffy]

@simonwidjaja

"draftAndPublish": true

Yes exactly, it’s due to drafts. We don’t apply required validation on drafts but if you try to publish it, it won’t let you til you fill the field. We assume drafts are a WIP and don’t want to force a user to put information they don’t know.

[DMehaffy]

I’ll poke @Aurelsicoko and @sam-pires as to why that choice was made.

[simonwidjaja]

Thanks for your reply. Your use case description makes totally sense. I had two different specific use cases where I expected it to be different. I interpreted “draft” more like “release candidate (valid but not published yet)”. e.g. scheduled posts. They should be 100% valid but in unpublished state.
Hope that description makes sense…

Another kind of annoying thing I experienced several times now:
When I remove the draftAndPublish feature for a collection at a later point, the default behavior (and only option) currently is to delete/lose all “drafts”. (Or publish each and every document before removing the feature). That is pretty bad, since draftAndPublish is activated by default. A nice option (feature request) would be an alternative option to keep ALL document no matter what state they were in (draft and published). This would have saved me lots of time and trouble several times already… This is especially true for strapi beginners… And it should be pretty easy to implement.

Besides that I love the draftAndPublish feature!
Keep up the amazing work!

[sam-pires]

Thanks for the feedback @simonwidjaja!

Indeed, we don’t apply some validations on draft content, “required” is one. We identified that the work on draft contents often takes several days and involve several people depending on the workflow. And as @DMehaffy mentioned, we decided to make it more flexible by removing some validations, so a user can just work on a part of a content and still be able to save.
Right now in the first version of the feature, we didn’t implement options to select whether validations should apply or not to drafts, but that’s definitely something we’ll think about for the next improvements.

Now regarding what happens when someone disable the D&P feature on an existing CT, we put a lot of thoughts into that haha
Again, for the first version and to limit the complexity we enforced deleting all the drafts. The reason is to avoid making all the draft contents accessible through the API if someone disables D&P, which can be critical. But still let the possibility to update all the drafts and publish them to avoid losing them (which kind of make sense, if you want to keep them without D&P they should be ready to be accessible)
Here again, I’ll put your feedback in our list of suggestions to improve the feature, which could be useful to have several options

Thanks!
And glad you like the feature

[DMehaffy]

My minor suggestion would be to not enable D&P by default for the number 2 issue

[sam-pires]

I know you don’t like it enabled by default @DMehaffy

We plan on checking the feature usage soon to see if it makes more sense to enable or disable it by default, we’ll see at this moment. But what motivated our choice initially was to make it easier to quickly setup a publication workflow with the feature. I agree, there are some drawbacks, having to delete/publish all drafts to keep them is one indeed.

[DMehaffy]

Related Feature request: Disable Draft&Publish by default or add ability to control default state of it · Issue #9707 · strapi/strapi · GitHub