Contrib.social

Field type (item) classes implementing AllowedValuesInterface::getPossible(Values|Options)() is incompatible with Views and possibly other use cases

Open on Drupal.org →
Created on 18 July 2014, almost 11 years ago
Updated 3 June 2025, 24 days ago

Problem/Motivation

  • AllowedValuesInterface documents getPossible*() as being intended for configuring search filters, which for the use case of entity fields, means you don't have a concrete entity you're working with, but are configuring something that might return 0, 1, or N entities.
  • Some of HEAD's implementors of AllowedValuesInterface are field type classes, such as ListItemBase and ConfigurableEntityReferenceItem.
  • This means you need an instance of a field item (and therefore, an instance of an entity) in order to invoke a getPossible*() method on it.
  • If you're configuring a search filter that is specific to a bundle, then you can create a fake entity in order to get the field item object. This is ugly, but possible.
  • If you're configuring a cross-bundle search filter (e.g., a Views filter), then to create a fake entity, you need to decide on an arbitrary bundle to use, and the result you get back would be specific to that bundle. We could choose to document somewhere that getPossibleValues() must return the same data regardless of bundle, but the labels returned by getPossibleOptions() should be allowed to vary by bundle, but in a cross-bundle search, you wouldn't necessarily want those bundle-specific labels.
  • In core, we've circumvented this problem by not having Views filters for ER fields (the filter can be applied via a relationship instead) and having ListItemBase delegate getPossibleOptions() to options_allowed_values(), which Views can call directly rather than via a ListItemBase object.
  • But, do we want to come up with a better pattern for contrib field types to use?

Proposed resolution

  • Either decide that what we have in core is ok, and that contrib field types can invent their own delegation mechanisms similar to options_allowed_values(), and Views and other cross-bundle use cases will need to invoke those mechanisms as appropriate on a per-field-type basis.
  • Or, come up with a field system API that allows a bundle-independent object that implements AllowedValuesInterface to be retrieved. See #2238085-15: [regression] options_allowed_values() signature doesn't allow for Views filter configuration → for one such proposal.
📌 Task
Status

Postponed: needs info

Version

11.0 🔥

Component

field system

Created by

🇺🇸United States effulgentsia

Live updates comments and jobs are added and updated live.
  • VDC

    Related to the Views in Drupal Core initiative.

  • stale-issue-cleanup

    To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

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.

  • Comment 24 days ago →
    🇺🇸United States smustgrave

    Thank you for creating this issue to improve Drupal.

    We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

    Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

    Thanks!

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024