[meta] Add constraints to all config entity types

So I guess this is not as interesting to the Rest folks, and I guess should be a (single ?) separate issue, anyway, but we should add constraints to simple (i.e. non-config-entity) configuration, as well, I guess.

Can you clarify #7? Not sure what you mean by "methods". We already have ConfigInterface::save($has_trusted_data) so we could to config validation if $has_trusted_data is FALSE, but that would be kind of a behavior change as that is currently the default.

#2870878: Add config validation for UUIDs landed!

We said at #2300677-115: JSON:API POST/PATCH support for fully validatable config entities.15 that this can happen in parallel with that. But I'm actually not entirely sure that that makes sense — without the ability to add REST test coverage, I'm not sure how much can be done in this issue's child issues?

WFM :)

I've created #2920441: Add config validation for workflow entities to cover the workflow config entity. I think given we're doing a lot of validation at the API level, it'll be an interesting challenge to try and cover these same scenarios as constraints and might serve as a road-test of the API in preparation for #2300677: JSON:API POST/PATCH support for fully validatable config entities.

That looks better, thanks.

The first property to validate was the ID, which applies to lots of entity types. Adding to the list of generic validations.

Next cab off the rank is also something which I think is generic.

Promoting this to Major, because it's a blocker to #2300677: JSON:API POST/PATCH support for fully validatable config entities.

I was looking at using configuration constraints based on what I see in system.sites.yml:

    uuid:
      type: uuid
      label: 'Site UUID'
      constraints:
        Uuid: []
        NotNull: []

I experimented with this type of configuration for the site uuid, and for the site name and I was unable to trigger and validation errors. I tried setting values in the UI, config import/export and drush config-set.

Is that a not fully implemented feature? Or is this "constraints:" setting being used in a way that is not obvious? I realise this issue is about config entities, but it seems a good place to discuss since the IS links to the issue that introduced that Uuid: [] line.

I only now re-discovered this issue 😬

See #2164373-34: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs … for a summary of the progress in the last month. And also especially see #3324984: Create test that reports % of config entity types (and config schema types) that is validatable, where it becomes possible to automatically track how much work remains!

I think we should consider closing this in favor of #2164373.

Thoughts?

Actually, #2164373 is getting impractically broad. Let's keep this for coordinating for config entity types.

This blocks #2300677 — see #2300677-258: JSON:API POST/PATCH support for fully validatable config entities.

Great news!

Per #3324984-35: Create test that reports % of config entity types (and config schema types) that is validatable, system.menu.* and shortcut.set.* are done!

They look like this:

system.menu.*:
  type: config_entity
  label: 'Menu'
  mapping:
    id:
      type: machine_name
      label: 'ID'
      # Menu IDs are specifically limited to 32 characters, and allow dashes but not
      # underscores.
      # @see \Drupal\menu_ui\MenuForm::form()
      constraints:
        Regex:
          pattern: '/^[a-z0-9-]+$/'
          message: "The %value machine name is not valid."
        Length:
          max: 32
    label:
      type: required_label
      label: 'Label'
    description:
      type: label
      label: 'Menu description'
    locked:
      type: boolean
      label: ''

and:

shortcut.set.*:
  type: config_entity
  label: 'Shortcut settings'
  mapping:
    id:
      type: machine_name
      label: 'ID'
      # Shortcut set IDs are specifically limited to 23 characters, and allow
      # dashes but not underscores.
      # @see \Drupal\shortcut\ShortcutSetForm::form()
      constraints:
        Regex:
          pattern: '/^[a-z0-9-]+$/'
          message: "The %value machine name is not valid."
        Length:
          max: 23
    label:
      type: required_label
      label: 'Label'

They are very simple config entity types for sure, but … hey, we've got to start somewhere! 😊

EDIT: this means #2300677 is unblocked, see #2300677-260: JSON:API POST/PATCH support for fully validatable config entities 🚀

Since #42: one more landed (DateFormat), two more in progress (Editor and Vocabulary)!

RDF is removed. Test-only config entity types do not necessarily need this IMHO. Let's tighten the scope to config entity types that are actually used in this meta.

Forgot that BlockContentType also landed!

I got #2920441: Add config validation for workflow entities started too — now 100% of the issues listed in the issue summary have an in-progress MR, some RTBC, some nearly, some with still a long way to go.

Progress! 😊

#2002174: Allow vocabularies to be validated via the API, not just during form submissions landed! 🚢

#3412361: Mark Editor config schema as fully validatable landed!

#3379725: Make Block config entities fully validatable is moving forward — probably one of the most important config entity types to make validatable because most sites have a fairly large number of these.

The list has gotten shorter thanks to #3422600: Remove Tour module 🤓

Cleaned up, and now with detailed statistics:
Total: 7/28=25%
Standard: 7/23=30%

(just like the sibling issue #2952037: [meta] Add constraints to all simple configuration)

image.style.* is in!

3 more config entity types are now fully validatable! 🚀

#3379725: Make Block config entities fully validatable is in!

#3458321: Add validation constraints to language.content_settings.*.* landed!

Updating for #68 + #69.

When working on #2300677: JSON:API POST/PATCH support for fully validatable config entities i did notice after actually enabling tests for all validatable config entities, that although system.action.* is validated, the plugins aren't. So when testing, using user_unblock_user_action it errors on that fact.

Not sure if would have marked action as validatable when the configuration you might be able to put in there (from core) is not.

Well, system.action.* is fully validatable, but you are right that the plugins aren't.
Depending on the metric you use, all the config in core is at around 42% validatability. https://project.pages.drupalcode.org/config_inspector/

So, if we would have to keep all the plugins in mind as well, I think we would probably have to remove even more of the checkmarks from this list. I don't think we have open issues for all the plugins, but I guess we can create those issues to make the plugin validatable again.

#3508308: Validate system.action.*: add new Constraint RoleExists was merged

#3448457: Add validation constraints to core.entity_form_mode.*.* is in :)

Removed contact from the list, now that's no longer in core.