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, almost 11 years ago
Updated 28 February 2023, about 2 years 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 about 17 hours 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