Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
This is being introduced for view modes in #1043198: Convert view modes to ConfigEntity, but should be useful for many ConfigEntities.
We already have this currently for node types (which aren't ConfigEntities yet).
Proposed resolution
Add a 'locked' property on ConfigEntityBase.
Remaining tasks
Write patch.
User interface changes
None.
API changes
None.
Related
#1882552: Deprecate menu_list_system_menus() and menu_ui_get_menus()
Comments
Comment #1
sunOff-hand, I'm really not sure whether every config entity needs a $locked property/flag. It appears to me that this is rather a concept for config entities that present bundles for other entities?
Actually, I think we should start to approach the idea I mentioned in #1847132-3: [EntityDisplay] Convert view modes config to CMI:
Comment #2
swentel commentedDuplicate of #1714396: Offer ability to 'lock' config changes ?
Comment #3
sun#1714396: Offer ability to 'lock' config changes is a different kind of lock — it means and wants to lock the entire site configuration, not just a single config object.
Comment #4
tim.plunkettComment #5
yched commentedI don't think we can provide a 'locked' property with a universal meaning across config entities.
What #1043198: Convert view modes to ConfigEntity wants to introduce is "do not allow UI modifications of this element".
OTOH, Field API has $instance['locked'], whose semantics is "do not allow UI deletion but allow modifications : change widget, change display settings, reorder in the node edit form...".
Comment #6
tstoecklerActually that is not true. We do want the everything on the view mode to be editable but for the machine name. For the view mode that turns out to be only the label (we currently do not provide a checkbox for the "custom" property). So I think the concept does actually match. Equally for node types (except that they're not ConfigEntities yet). I have no problem with letting each ConfigEntity figure this out on their own for now and later (as in next spring) seeing whether we can consolidate stuff, but I am pretty certain that what e.g. the ViewModeListController is doing in the referenced issue (i.e. hide the delete link in case the item is locked, lock the machine name if the item is locked, ...) will turn out to be pretty generic.
Comment #7
sun#1479454: Convert user roles to configurables could also use a locked property for the two built-in roles 'anonymous' and 'authenticated'.
The use-case over there seems to be identical:
1) Do not allow deletion. (delete)
2) Do not allow to change the ID/machine-name. (rename)
As @tstoeckler already mentioned, I too think that the semantics are actually identical for all use-cases.
However, I will certainly agree that the property name "locked" suggests a whole different meaning — namely, that the entire thingie is locked in the sense of uneditable, undeleteable, unrenameable. Therefore, "locked" is a rather confusing property name.
I'd see two options out:
Rename "locked" to something that encompasses the implied meaning only; e.g., "required".
(i.e., the config object is required to exist as-is.)
Explode and drill down the sub-meanings into actual sub-properties.
This could have the benefit of more flexibility in the long run to explicitly support denying of certain config operations; e.g.:
So if you'd create a default config object that adds
locked.save = 1to that, then you'd effectively have an object that is "truly" locked and which cannot be deleted, nor renamed, nor saved. Only a rawconfig()operation is able to change it or by touching/hacking the config file manually, but in either case, you'd be on your own, since you've changed a config entity without going through the API.In the same way, config entity types could also specify
locked.rename = 1only, which essentially translates into our legacy usage of #type 'machine_name' with a #disabled property for existing config entities (which was only enforced on the UI-level previously). We generally want to get rid of that disallowed-rename-only limitation for configuration in D8, but if a module would need to enforce that, then this might be the way to do so. Once we have a base ConfigEntityFormController for all config entities, we could supply the necessary UI/form logic as a built-in behavior.Likewise, people could come up with new
locked.editorlocked.invisiblesub-keys, which could have the hypothetical meaning of "hiding the config object" in the UI only, but allowing API-level operations.Note that the second option is only a possible option and suggestion. It seems to have a couple of benefits, but of course, it's also more verbose.
Also, regardless of which option, the proposed change of this issue essentially translates into a per-config-entity access mechanism on the API level, whereas the access parameters are stored within the config/data object itself. That generally sounds unorthodox, but I think it's appropriate for managing config entity objects.
Comment #8
andypostThis would be needed for #1882552: Deprecate menu_list_system_menus() and menu_ui_get_menus()
Comment #8.0
andypostUpdated issue summary.
Comment #9
effulgentsia commentedComment #10
andypostComment #11
tim.plunkettAdding #2605042: Cannot edit actions created by user_user_role_insert()
Comment #15
andypostComment #23
andypost