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: Get rid of menu_list_system_menus()

Comments

sun’s picture

Off-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:

In light of #1782460: Allow to reference another entity type to define an entity type's bundles

I wonder whether we shouldn't introduce a "formal" Bundle Configuration Entity Type; i.e., this:

namespace Drupal\Core\Config\Entity;

class EntityBundleBase extends ConfigEntityBase

...and now the tricky part:

This base class for all bundles would have public entity properties for the entity bundle settings that are expected + required for all entity bundles.

Thoughts?

swentel’s picture

sun’s picture

#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.

tim.plunkett’s picture

Component: entity system » configuration entity system
yched’s picture

I 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...".

tstoeckler’s picture

Actually 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.

sun’s picture

#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:

  1. Rename "locked" to something that encompasses the implied meaning only; e.g., "required".

    (i.e., the config object is required to exist as-is.)

  2. 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.:

    locked:
      delete: 1
      rename: 1
    

    So if you'd create a default config object that adds locked.save = 1 to that, then you'd effectively have an object that is "truly" locked and which cannot be deleted, nor renamed, nor saved. Only a raw config() 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 = 1 only, 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.edit or locked.invisible sub-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.

andypost’s picture

andypost’s picture

Issue summary: View changes

Updated issue summary.

effulgentsia’s picture

andypost’s picture

tim.plunkett’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.