Problem

We currently have 3 list field types for floats, integer and text. Those field types do not provide a different data model than the regular float, integer or text field types - still they are totally different field types with totally different widgets and formatters.
Also, when we bake the API to set options into the field definition API as proposed by #2329937: Allow definition objects to provide options it would be strange DX when it would require you a certain field type for being able to use it also.

Proposed resolution

Merge the functionality of providing allowed values in the main field type and make the functionality optional. This comes with the advantage that you can easily switch back and forth between having allowed values or not and it allows for combinations not possible before, e.g. you could use a regular textfield widget for input numbers with allowed values 1-5, coming with different labels also.

Example use case: a textual input score field 1-10, which is limited from 1 to 10 and each level gets its own label used during display.

If we don't do this, list_text should be changed to list_string to match the new repartition of text/string field types.

Remaining tasks

Figure out the best way option widgets can identify compatible field types and do it.

User interface changes

List field types go away, all float, integer and text field types get a new optional allowed-values setting.

API changes

None, but the list of available field types changes.

Comments

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Issue tags: -beta deadline +beta target, +D8 upgrade path

This would be a useful UX improvement (at least it definitely would for me), and it doesn't require any migration except for field types, so switching tags a bit.

yched’s picture

yched CreditAttribution: yched commented

Note that this was the case in CCK D6, and the list field types were separated in D7.

IIRC, that was because "maybe it has a limited set of values, maybe it's open" was cumbersome for the eligibility of widgets and formatters (you could chose a select widget on a text field with no configured allowed values, and the dropdown was just empty / broken). That might be alleviated with the recent eligibility method in widget/formatter interfaces.

Also, it made the procedural code for those field types painful - but that may be alleviated by making ListItemBase a trait now ?

Last, this makes me think that, if we dont do this, list_text should in fact be list_string, to match the new repartition of text/string field types.

yched’s picture

yched CreditAttribution: yched commented

More thoughts:
- the combination of a list of "allowed values" with other settings intended to limit "open values" (max_length, min/max value) doesn't make much sense.
- list field types prevent the removal of an "allowed value" that is currently used in actual field values. Would we be able to do this in the case of a field that was "open values" so far and that gets assigned a list of "allowed values" at some point ?

In short, the field types were separated because in practice "open values" and "limited allowed values" have different logic and configuration, and allowing to changw back and forth between the two is both non trivial and not that much of an actual use case

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir commented

I discussed this a bit with @catch in IRC, it is not an easy problem to solve, there are a few things that we need to think about:

- While we now have an API to dynamically figure out applicable widgets, we still assume that the default widget is always available. Switching to/from an allowed list of valued would result in a different default widget, I don't know how we're supposed to support that?

- Similar, if you change it for an existing field, then what happens with the existing display configuration that is now invalid?

- Widgets/Formatters can currently not apply to all field types, the isApplicable() stuff only works as a secondary layer.

- Currently, changing allowed values does validation, you can not remove an option if it is used. This is list field type specific logic, and if we want to keep that (not doing it could have problematic side effects too), we need to figure out a way to switch, otherwise a user has to know every value that is currently in the database or he will not be able to save it.

There was more, but I can't remember it right now...

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

This would be a useful UX improvement (at least it definitely would for me), and it doesn't require any migration except for field types, so switching tags a bit.

I thought it's important to get right now as it requires people to use the right field types when definiting their entities, however it would be easy to keep old list_* types in place for BC.

In short, the field types were separated because in practice "open values" and "limited allowed values" have different logic and configuration, and allowing to changw back and forth between the two is both non trivial and not that much of an actual use case

Yeah, when describing the use case above I was actually thinking that it sounds a bit like adding some labels for values of an "open values" field type instead of being a limited values field type.

Switching to/from an allowed list of valued would result in a different default widget, I don't know how we're supposed to support that?

We could move the default value definition to a method, what would help with #2342569: Decide on a strategy to handle huge lists of options also.

- Similar, if you change it for an existing field, then what happens with the existing display configuration that is now invalid?

That is indeed tricky - we'd have update it to be the default widget when the current widget is not eligable any more :/

- the combination of a list of "allowed values" with other settings intended to limit "open values" (max_length, min/max value) doesn't make much sense.

Agreed, so the form would become more complex then in order to reflect that.

- list field types prevent the removal of an "allowed value" that is currently used in actual field values. Would we be able to do this in the case of a field that was "open values" so far and that gets assigned a list of "allowed values" at some point ?

hm, I guess we'd have to be picky when introducing allowed values or reducing them.

Also, it made the procedural code for those field types painful - but that may be alleviated by making ListItemBase a trait now ?

That would make sense to me.

Generally, I agree that this is no simple change and comes with quite some non-trivial edge-cases.

yched’s picture

yched CreditAttribution: yched commented

Myself in #2:

this makes me think that, if we dont do this, list_text should in fact be list_string, to match the new repartition of text/string field types.

Posted a patch in #2344979: Rename field type list_text to list_string. Since this issue here is still highly unsure, and the rename above would need to happen before beta, we want to move forward asap over there IMO.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom commented

Is this issue still on the table for 8.0?

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
CreditAttribution: jhedstrom commented
Version: 8.0.x-dev » 9.x-dev
Status: Active » Postponed

I think this is too late for 8.0 at this time.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch as a volunteer commented
Version: 9.x-dev » 8.1.x-dev

I think we could add the functionality to the core filed types, deprecate the old ones, possibly deprecate and hide list module itself on new installs.

jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented
Status: Postponed » Active
andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
Issue tags: +Needs issue summary update

Can we have upgrade path for all configs that using types to rename?

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Issue tags: -beta target

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

Rebecca Crago’s picture

Rebecca Crago CreditAttribution: Rebecca Crago as a volunteer commented
Issue summary: View changes

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.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.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

quietone’s picture

quietone CreditAttribution: quietone at PreviousNext commented
Issue tags: -D8 upgrade path +Upgrade path

Updating tag.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now 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: 10.1.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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.