Do not allow to alter Locked field via UI

@smustgrave, thank you for your patch in #138! I just tested it and it works as expected! :) RTBC+1

BUT:
I disagree it's the final solution and don't think 🐛 Locked fields can change the widget but not settings Needs work should have been closed as duplicate. This issue is only about disallowing to edit the field storage related configuration like cardinality. That's totally fine and a clear bug that should be fixed!

But on the other hand, and that was also an aspect of the other issue, the locked: true on field storage configuration currently also locks editing field instance related configuration, like field instance

• label
• description
• default values

which is also an important issue.

So I decided to create a separate issue for that: 🐛 Locking field.storage should not lock field instance settings (field.field) Active instead of reopening 🐛 Locked fields can change the widget but not settings Needs work . I hope that's more specific.
Both should be solved.

Updating credits since I re-opened 🐛 Locked fields can change the widget but not settings Needs work .

I agree that the current logic is kind of wrong as argued by #113. However, the config entities being separate for field storage and field instance tends to be more of an implementation detail. I can't think of a use case where users would actually want to customize permissions for these two forms separately.

I think it might make sense to hold off making this change because we are looking into combining these two forms in 📌 Combine field storage and field instance forms Fixed . Keeping the access controls tied together like it is currently, would be simpler from that perspective.

I'd recommend that we keep the keep the access control to two of these config entities connected, and we add additional access control to \Drupal\field\FieldConfigAccessControlHandler::checkAccess to prevent editing locked field configs.

@lauriii:

I can't think of a use case where users would actually want to customize permissions for these two forms separately.

That might be true. The point is, that if it's separated in the data model, it's at least possible and I'm not sure we should assume that.

One typical example that happens very often for us is, that the default value should not be locked, in contrast to all other field stuff. The default value is often very site-specific, while the fields / schema is general.
As written above, it's currently locked by the form, as it's in the wrong place. Locked by the the field storage lock in the UI, but belonging to the field instance, that should not be locked. See #140.

I think it might make sense to hold off making this change because we are looking into combining these two forms in #3347291: [PP-1] Combine field storage and field instance forms.

Agree, would be nice, if the points from about could be taken into account.