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.
Comment | File | Size | Author |
---|---|---|---|
#14 | 3045309-14.patch | 9.69 KB | jrockowitz |
| |||
#12 | 3045309-12.patch | 5.66 KB | jrockowitz |
| |||
#9 | 3045309-9.patch | 5.71 KB | jrockowitz |
| |||
#5 | 3045309-5.patch | 4.5 KB | jrockowitz |
#4 | 3045309-4.patch | 4.81 KB | jrockowitz |
Comments
Comment #2
michaelschutz CreditAttribution: michaelschutz commentedComment #3
michaelschutz CreditAttribution: michaelschutz commentedediting again to simply edit the content - didn't see that revisions are tracked...
Comment #4
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedI am probably still okay with…
I am not okay with…
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.
Comment #5
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThis patch is a slightly safer approach which prevents anyone from altering composite element options set via the source.
Comment #6
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedComment #9
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedFixing 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
.Comment #10
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedComment #11
michaelschutz CreditAttribution: michaelschutz commentedLet 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!
Comment #12
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThanks!
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.
Comment #13
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedPlease also review the change record.
Comment #14
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedThe attached patch includes test coverage.
Comment #16
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commented