I was having an issue with a Province/State field in a Basic Address element. I could choose between the "State/Province Codes" option and the "State/Province names" option. But since those only have US states, and I wanted to include/prioritize Canadian provinces, I created a new Options list, as suggested.

However, this was not being added to the available Options for selecting in the Webform UI for that field in the Basic Address element. And I could find no way to tell the field, "hey, there's a new Option group available to choose". Only the two default options were allowed to be chosen from.

Searching led me to https://www.drupal.org/project/webform/issues/2937109, which gave me the clue I needed to make it work. I could just paste the machine name of my new Option group into the Source/YAML of my form.

That works fine, but it seems like a big workaround, and there's an additional problem: if I re-visit the field through the UI and don't make any changes, it's fine. But if I make a change to something in the UI, it throws an error upon Save because the "State/Province" field select list isn't actually pointing at anything. So after I make any change in the UI, I have to choose one of the default options, then go back into the Source and re-input the proper Option machine name.

Once saved properly, the Options config page properly reports that it's being used by this webform.

I'm reporting this as a bug, even though jrockowitz indicates in the above-linked thread that you'd prefer not to create a UI for this type of thing. I get that desire, but then it seems the usability is severely limited, since it's not at all intuitive that an admin can't simply create a new Option group and then have it available for any given select field. And, further to that, there's then a mismatch between the UI and the YAML, which leads to the "Select is required" error when making any change to the field through the UI.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

michaelschutz created an issue. See original summary.

michaelschutz’s picture

Issue summary: View changes
michaelschutz’s picture

Issue summary: View changes

editing again to simply edit the content - didn't see that revisions are tracked...

jrockowitz’s picture

I am probably still okay with…

Adding custom Options to a Select must be done in Source/YAML

I am not okay with…

But if I make a change to something in the UI, it throws an error upon Save because the "State/Province" field select list isn't actually pointing at anything. So after I make any change in the UI, I have to choose one of the default options, then go back into the Source and re-input the proper Option machine name.

The attached patch prevents options entered via the source from being deleted/remote.

Below is a screenshot of the warning message. Attached is also the webform that I used to test this change.


jrockowitz’s picture

This patch is a slightly safer approach which prevents anyone from altering composite element options set via the source.

jrockowitz’s picture

Status: Active » Needs review

The last submitted patch, 4: 3045309-4.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Status: Needs review » Needs work

The last submitted patch, 5: 3045309-5.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

jrockowitz’s picture

Fixing this is requiring an API change to the declaration of Drupal\webform\Plugin\WebformElement\WebformCompositeBase::buildCompositeElementsTable(array $form, Drupal\Core\Form\FormStateInterface $form_state) which is protected method.

At the very least this requires a change record and possibly being postponed until Webform 6.x.

If this change is committed, it will cause a fatal error to any custom composite that overrides WebformCompositeBase::buildCompositeElementsTable.

jrockowitz’s picture

Status: Needs work » Needs review
michaelschutz’s picture

Let me just say, jrockowitz, you are awesome. Webform is such a powerful and deep module, and you're incredibly responsive to even esoteric things like this.

I will apply this patch and test it out. Thank you!

jrockowitz’s picture

Priority: Normal » Major
FileSize
5.66 KB

Thanks!

The attached includes a minor tweak.

I think we need to fix this issue because it does result in losing custom options via the UI.

jrockowitz’s picture

Please also review the change record.

jrockowitz’s picture

The attached patch includes test coverage.

  • jrockowitz committed 32d5f62 on 8.x-5.x
    Issue #3045309 by jrockowitz: Adding custom Options to a Select must be...
jrockowitz’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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