Fix allowed values for field type "Options email" (contact_storage_options_email) in Drupal 10.2

Created on 22 November 2023, 12 months ago
Updated 6 July 2024, 5 months ago

Problem/Motivation

In Drupal 10.2+ changes for ListItemBase was made 📌 List key|label entry field is textarea, which doesn't give guidance towards the expected input Fixed .
It's impossible to set allowed values with UI for field type contact_storage_options_email.

Steps to reproduce

1) Create new field with type "Options email" (contact_storage_options_email).
2) Allowed values is not possible to set.

Proposed resolution

Remaining tasks

  1. Change OptionsEmailItem::extractAllowedValues params.
  2. Fix Field UI.
  3. Fix tests. ContactStorageTest::testContactStorage is affected.

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Fixed

Version

1.0

Component

Code

Created by

🇷🇺Russia zniki.ru

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @zniki.ru
  • Status changed to Needs review 12 months ago
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.3 & MySQL 5.7
    last update 12 months ago
    Patch Failed to Apply
  • 🇷🇺Russia zniki.ru

    There is at least 2 solutions to fix it:

    1. Return back for textarea field for providing allowed value.
    2. Add field for email, and provide support for these fields.
    3. Combine 2 options, and allow user to chose between new UI with text field, and old with textarea.

    If we are going to use option #1, it will takes less time to implement, but we are not using new Drupal UX
    It's possible to copy old version of \Drupal\options\Plugin\Field\FieldType\ListItemBase to code base of the module, and then use it to extend Drupal\contact_storage\Plugin\Field\FieldType\OptionsEmailItem. It would be easier for experienced site builders to create new category, just copy "allowed values" from one field to another.

    To use option #2 a lot of changes to OptionsEmailItem needs to be made.
    I make fast check, and it's easy to achieve with core patch (patch attached), but it takes a lot effort to implement it in OptionsEmailItem.
    It would be great to be able to select form widget for allowed values as we do for fields, but this is impossible for now.

    Most user friendly is option #3, users can decide to use new form with textfields, or old one with textarea.

    I think it would be great to discus it before starting implementing changes.

  • Status changed to Needs work 12 months ago
  • 🇨🇭Switzerland berdir Switzerland

    I misunderstood this, forgot about this field type.

    I'd suggest to just revert to the plain textarea UI.

    The patch above seems to be against core.

  • Merge request !9Issue #3403403: Fix allowed values → (Merged) created by zniki.ru
  • Status changed to Needs review 12 months ago
  • 🇷🇺Russia zniki.ru

    Yes the patch in #2 is against Drupal core. After applied changes I was able to use 3 fields for allowed value. Key, Label, Email.
    I provide it, as information for anyone who wants to experiment with implementing support for 3 fields.

    I create draft MR, just copied ListItemBase and renamed it from 18432dac and used it as parent for class OptionsEmailItem.

    Do you think this is the right way?

  • Pipeline finished with Success
    12 months ago
    Total: 183s
    #54408
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.3 & MySQL 5.7
    last update 5 months ago
    8 pass
  • Pipeline finished with Skipped
    5 months ago
    #205465
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.3 & MySQL 5.7
    last update 5 months ago
    8 pass
  • Status changed to Fixed 5 months ago
  • 🇨🇭Switzerland berdir Switzerland

    I'm not sure if there would be a way to do it with fewer duplication or if we could somehow adapt the UI, but lets go with this as an initial fix. Merged to unblock failing tests.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024