Part of #2144263: Decouple entity field storage from configurable fields:

  • The field ui flag determines on whether the Field UI is enabled. @yched pointed out this is not necessarily about configuring fields, but works for entities just having base fields but do not allow adding custom fields also. So it should be renamed, e.g. to admin ui.
  • configurable fields is a new boolean flag and used by the Field module to know whether it should support the entity type and by Field UI to know whether it is allowed to add fields via the UI.

Comments

plach’s picture

Berdir’s picture

Not sure what kind of flags this is talking about, is this on field types?

We already killed the configurable flag for field types, there's no separation there anymore, the only thing that does exist is no_ui, which is now used for a number of core fields types that are pointless to be added in the UI. Note that a field type also needs a default widget and formatter to be shown in the UI.

So, I have no idea what to do here :)

Berdir’s picture

Title says Entity Type properties, but there is nothing like that on entity types right now?

plach’s picture

fago’s picture

The field_ui flag was probably only there temporarily. Right now field ui does the following check:

if ($entity_type->isFieldable() && $entity_type->hasLinkTemplate('admin-form')) {

So the field ui flag is replaced by the admin-form link template. However, field ui should be enabled for non-extendable entity types also, but limit its support for adding-fields based on either the extendable/fieldable flag or the new "configurable fields" flag.

However, "configurable fields" would impose ignoring the entity type from within field.module, what I do not see any reasons doing so. Much rather people might want to disable extendability in the UI, so maybe "UI extendable" or so would be a better name?

fago’s picture

Berdir’s picture

Status: Active » Closed (duplicate)

I think we can close this as a duplicate of the other?