Add constraints to all config entity types

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

This blocks #2300677 — see #2300677-258: [PP-2] POST/PATCH config entities via REST for config entity types that support validation → .

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! 😊

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 📌 Add config validation for workflow entities. Active 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! 😊

📌 Allow vocabularies to be validated via the API, not just during form submissions RTBC landed! 🚢

✨ [PP-1] Mark parts of CKEditor 5 and Editor config schema as fully validatable Postponed landed!

📌 Make Block config entities fully validatable Fixed 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 📌 Remove Tour module Postponed 🤓

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

(just like the sibling issue 🌱 [meta] Add constraints to all simple configuration Active )

image.style.* is in!

3 more config entity types are now fully validatable! 🚀

📌 Make Block config entities fully validatable Fixed is in!

📌 Add validation constraints to language.content_settings.*.* Needs work landed!

Updating for #68 + #69.

When working on ✨ [PP-2] POST/PATCH config entities via REST for config entity types that support validation Needs work 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.

#224480: Transactions from User Points Basic showing "insert" as operation → was merged