Select with empty (pre-built) option list should not be shown

I don't think the field should be hidden entirely. My expectation would be that the select list would be present but be empty. I suppose there's no such thing as an "empty" set of checkboxes or radios though. Still, I think the element should be present but have a message or indicator there are no valid options. If the field was entirely hidden, as an end-user I'd think there was a problem with the module, rather than the view simply being empty.

So I think we should handle this scenario, but rather than hiding the entire select component, some kind of placeholder should be present.

Hi.

I tried it on Webform 4, but does not work. I think it should work.

I really need it. Any help is welcome.

Thanks, regards

I've had this issue as well. My 'solution' was to pop in a default row of {null-key}|{Notification of no options available}.
Of course, this requires that you then handle the special option correctly. If the form needs to block submission when no option is available you may need to set up a conditional to throw an alert when the {null-key} option is selected.

Thanks ! RedEight:

I need to hide the element but I using tokens fields like %username (Webform 3)

Can you help me?

Thanks ! a lot.

This won't be addressed in 7.x-3.x, but should be in 7.x-4.x and 8.x.

I'm mixed about how how to handle this. The proposed patch is simple, and this is not a common case. Adding some sort of placeholder message creates the possibility of wanting to customize the placeholder message. I can imagine lots of use cases where having the placeholder isn't helpful, such as "No color options are available for this SKU". Why tell me that?

OTOH, quicksketch likes the placeholder approach.

I propose to accept the patch (re-rolled as needed).

Re-roll.

Small coding standards fix.

Please review.

Thanks @valentine94 for the re-roll. But please do test the patch before submitting it/them. There is no way for this patch to work because it sets the element's #access, which is then immediately overwritten in _webform_client_form_add_component().

The #10 patch prevents the overwrite. Note that it does NOT affect the display of a submission, since in this case the list of options is not built. Since this issue handles an edge case, I did not deem it worthwhile to generate the list of options just to hide the submission.

Committed to 7.x-4.x and 8.x

This commit broke form builder, specifically, adding new option/checkboxes elements. the #access = FALSE in select.inc is the culprit.

@nod_ - I don't use form_builder. Can this be fixed in form_builder? If so, you could post a patch to its issue queue and refer to this issue. Otherwise I'd welcome a webform patch that is form_builder friendly and still fixes this issue.

I'm not familiar with either module code so I don't know if it can be fixed from form_builder properly. Reverting this commit makes things work for my demo.

I'm rather short on time this week so I'll have to get back to it later.

Can this be fixed in form_builder?

Please, see the new patch attached to #2383285: Options element stopped working

@Sneakyvv -- sorry. I picked up a year-old, forgotten issue, fixed it, committed it, and gave credit to the last working patch. I overlooked the work from the prior patch.