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.

Comments

effulgentsia’s picture

effulgentsia commented
Priority: Normal » Major
Issue tags: +typed data, +Entity Field API, +beta deadline

Tagging to match #2238085-7: [regression] options_allowed_values() signature doesn't allow for Views filter configuration, since this is a continuation of that original line of work before that issue became more targeted. Note, however, catch's comment immediately following that related to whether this could be done in a way that maintains enough API compatibility to go in after beta.

Setting priority to major instead of critical, since the critical part of that issue was a Views regression from D7 related specifically to list fields, which is addressed in that issue. Providing a unified, cross-field-type API might be nice, but I don't know what would justify that being critical.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: +VDC
fago’s picture

fago
Primary language German
Location Vienna
commented

I do think the current situation is rather sub-optimal and I'd love to see a decent solution to be used that solves the problems outlined here and covers our other use cases on context definitions as well. Therefore, I opened #2329937: Allow definition objects to provide options for the proposed solution.

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented

Another use case would be #2332833: Allow range when editing a number field which could have a <datalist /> element containing key|value pairs.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue tags: +Pre-AMS beta sprint

Tagging as a priority for a pre-AMS beta sprint.

catch’s picture

catch
he/him
Primary language English
commented
Issue tags: -beta deadline, -Pre-AMS beta sprint +minor version target

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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

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!

smustgrave’s picture

smustgrave commented

Wanted to bump 1 more time, assuming still valid?

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: Field type (item) classes implementing AllowedValuesInterface::getPossible(Values|Options)() is incompatible with Views and possibly other use cases » OptionsProviderInterface needs FieldItem (but often like in Views you haven't!)
Issue tags: +Needs issue summary update

Yes it is. The interface name changed, the problem persists.
The implemntation of OptionsProviderInterface should move from FieldItem to FieldDefinition, with deprecation dance.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: OptionsProviderInterface needs FieldItem (but often like in Views you haven't!) » OptionsProviderInterface sits on FieldItem, should on FieldDefinition (because often like in Views you haven't!)
geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Title: OptionsProviderInterface sits on FieldItem, should on FieldDefinition (because often like in Views you haven't!) » OptionsProviderInterface sits on FieldItem, should on FieldDefinition (because often like in Views you have no item!)
geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Status: Postponed (maintainer needs more info) » Active
geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Status: Active » Closed (duplicate)
Related issues: +#2329937: Allow definition objects to provide options

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.