Clarify what 'locked' means for a config entity and whether it's okay for code to rely on a locked config entity existing

Created on 20 June 2014, about 10 years ago
Updated 28 February 2023, over 1 year ago

We have several config entity types that have a 'locked' property:

  • Field
  • Language
  • DateFormat
  • Menu

For fields, all it means is that certain UI operations are prohibited, but the field can still be changed/deleted via API calls or a config deployment. We have an entire parallel concept and implementation of base fields to support the situation of code needing to rely on a field existing independently of config.

For the others, I'm not clear on what locked is intended to mean. However, I tested whether it's possible to delete a locked menu via a config deployment, and in fact, it is. But, doing so for the system.menu.admin.yml menu results in a WSOD because menu link rebuilding then fatals, because there are code-defined links (here I'm considering *.yml files in a module's root directory as part of the module's code, because only YAML files within the config directory are config) that reference that menu. I suspect similar code dependencies on locked date formats and languages also exist and would fatal if those "locked" entities got deleted via a config deployment, but haven't tested that.

Some questions resulting from this:

  1. Should we enforce "locked" at the deployment and entity CRUD API levels, thereby making it legitimate for code to depend on a locked entity existing? If so, that potentially opens the door to (though wouldn't require) removing the entire concept of base fields, and implement them as locked fields instead (see #2287727-15: Rename FieldConfig to FieldStorageConfig β†’ ).
  2. Should we define "locked" as merely a UI concept, and not enforce it at the deployment or CRUD levels? In which case, we need to fix code like menu link rebuilding to still function if the code-referenced config entity doesn't exist.
  3. Should we make this decision on a per-entity-type basis, in which case, we need to decide for each of the ones in HEAD, and document the meaning on each corresponding entity class's declaration of the $locked property.
πŸ“Œ Task
Status

Active

Version

10.1 ✨

Component
Configuration entityΒ  β†’

Last updated 2 days ago

Created by

πŸ‡ΊπŸ‡ΈUnited States effulgentsia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024