Hi,

most of the webform components have the ability to get disabled, so "setting an unchangeable default value" is possible.

I would need this functionality for Select options also. In my case users submit a previous webform where at one place they make choice from a select list.

After submission of this first webform, users get to a view, where the views-filters are actually the values from the webform. In this view users get to choose one of the results which takes them to another webform, where the have to enter their private data etc.

On this new webform I need to have some of the values, which have been submitted previously, show up again, as a summary. Some of those values are options lists. But they have to be "locked", as those values have already been set and are not to be changed.

The issue is NOT how to bring over the values from the one webform to another, thanks to http://drupal.org/node/1076124 this is now clear :). I just need this field "disabled"...

Any help is greatly appreciated.

Thanks in advance!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Status: Active » Closed (won't fix)

This won't be implemented because the property used for "disabling" (which is actually "readonly") doesn't work on select lists, radios, or checkboxes.

tahiticlic’s picture

Version: 6.x-3.8 » 7.x-3.19

Hi,

i had the same need.

Solved here : http://drupal.stackexchange.com/questions/832/how-can-i-disable-a-single...

BTW, disabled is perfectly correct on checkbox elements : http://www.w3.org/TR/html-markup/input.checkbox.html

dunecat’s picture

Version: 7.x-3.19 » 7.x-4.0-alpha10
Component: Code » Miscellaneous

Hi everyone,
I agree that it would be nice to have this functionality as opposed to show/hide that is available in Conditionals. In my case I have several sets of checkboxes, like such: one checkbox is an option, the other once that follow are the "dependent" checkboxes. Instead of hiding all the "dependent" sets, I would like to show them, but disabled, and only enable if the main one is checked in each set. (Hope I could explain it properly, I am sorry if I caused confusion). In my case I think it would improve user-friendliness as they will see all that they have to fill in.
Thanks

escoles’s picture

Another use-case: Visitors use the form to register for a number of events, some of which may be filled after n registrants. After that point, we'd want to still show the field, but disabled. In the current state, we can only do that if we have created single select-option elements for each registration.

escoles’s picture

Status: Closed (won't fix) » Active

Asking for reconsideration on this. 'Disabled' is valid HTML5 and there are legitimate use-cases.

Hakaku’s picture

Issue summary: View changes

I agree with escoles. His use-case example is precisely what I'm looking for.

rpsu’s picture

I am looking for this as well, however as I looked into how select options list is built it seems quite difficult to achieve this behaviour. Options are built with:
safe_key|Readable key
I was hoping to be able to build a simple module which would be able to change key to disabled state with adding one more parameter to that list:
safe_key|Readable key|disabled
However I did not yet find out where the actual select list options are built and if one could hook into that function to

  • change option title and
  • change it to disabled state

I did not try to change Webform module itself since this does not seem to be a widely requested behaviour and therefore it could perhaps be implemented in a separate module.

Any thoughts?

DanChadwick’s picture

Component: Miscellaneous » Code

If you want to post a patch, I'm sure that quicksketch and/or I would review it. Install git, checkout the 7.x-4.x branch, create a feature branch, do your work, then post a patch.

I would not use 'disabled' for translation reasons. I'd pick some character that would be very, very unlikely to be used, such as:

safe|[I'm disabled]

Brackets frequently mean "optional" though.

or maybe

safe|~I'm disabled.

or

save|!I'm disabled.

MrPeanut’s picture

@rpsu — I would personally love to see either a patch or a separate module. I'm trying to do the same thing as @escoles (#4). I've tried to use the code in the link that @tahiticlic provided but have had no luck.

rpsu’s picture

Version: 7.x-4.0-alpha10 » 7.x-4.x-dev
Status: Active » Needs review
FileSize
3.99 KB

I created a patch for this. Unfortunately Form API does not support disabling form select options one-by-one so we need to rewrite HTML after rendering is done. Luckily it is not that difficult.

Check this patch if it is clear enough.

EDIT: key-character is now ! ie. disabled options visible text has prefix, which is removed later on the process.
opt_key|!My option text

Status: Needs review » Needs work

Status: Needs work » Needs review
rpsu’s picture

Oh, forgot: patch covers only listboxes, not checkbox or radio lists.

Status: Needs review » Needs work
rpsu’s picture

This patch handles lists, checkboxes and radios effectively replacing patch in #10

rpsu’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
rpsu’s picture

Status: Needs work » Needs review
FileSize
3.93 KB

Trying again to pass tests.

RaulMuroc’s picture

Patch in #18 breaks the solution applied here for the webform conditional. :S without the page the solution for webform conditionals works like a charm.

DanChadwick’s picture

Re #19: I'm not sure I understand. Webform Conditional shouldn't be used with webform 7.x-4.x, which includes this functionality within core.

I am working on #1840776: Components with a value that are hidden by conditionals should be empty which will eliminate the javascript being run on the preview page, if that helps.

RaulMuroc’s picture

You are right, I was talking about webform 7.x-3.x. I took the patch here and adapted to 7.x-3.x and it broke webform conditional things so reverted. Anyway forget as we are not on the same version, will get an eye to the issue you reference me. Thank you.

dasjo’s picture

Raul, could you share the state of your 7.x-3.x patch and which errors you ran into so far? I might have an opportunity to work on this

RaulMuroc’s picture

@dasjo, sorry about that but I cannot. That change was made at the job in a enterprise's project and I changed it two weeks ago so I don't have access any more to repositories and projects and so to the patch. (what a pity).

DanChadwick’s picture

This patch can be used for "list box" select components, which are implement at HTML select elements.

For checkboxes (non-list box, multi-select) and radio buttons (non-list box, single-select), there is a much cleaner way: https://www.drupal.org/node/342316#comment-4732130.

It's been 4 years. Let's make a decision of some sort. I welcome comments -- in particular from other maintainers and heavy webform contributors -- about the future of this.

Proposed solutions for consideration

  1. Use this patch for select components and the referenced FAPI method for checkboxes and the referenced method for radios and checkboxes.
  2. Use jQuery for select elements.

User interface

  1. The user interface would continue to be a leading "!" in front of the human-readable option name. I don't believe any language uses a non-inverted exclamation to start a phrase.
  2. Alternatively, we could pick another common symbol, such as tilde (~). However, that symbol is sometimes used to mean about, as in "~ 2 cups flour".
  3. Or slash (/), which has connotations of "no", at least to me.
  4. Another alternative would be to allow a list of keys of disabled options. This would make pre-built lists unable to use disabled though.

Deployment options
Reference: D8 core issue: #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent..

  1. Implement now in 7.x-4.x.
  2. Implement later in 7.x-4.x, if/when this is supported in D8.
  3. Defer to webfor 8.x
quicksketch’s picture

This patch can be used for "list box" select components, which are implement at HTML select elements.

Did you mean to include a patch? I'm not sure which patch is being referred to here.

I think it would be nice to support disabled checkboxes/radios as there is a native HTML way to represent that. Select lists: I'd like to avoid anything elaborate that further differentiates Webform forms from other Drupal forms. I'll have to see what jQuery solution is being recommended.

I'd also like to make sure that whatever solution we decide upon it's still compatible with Options Element.

DanChadwick’s picture

@quicksketch -- The patch I was referring to is #18. We'd need to write the patch for checkboxes/radios, but that should be trivial.

The jQuery would receive some settings and disable those options in the select.

I think all of these are compatible with options elements.

quicksketch’s picture

Oh... I didn't realize that disabled works on select list <option> elements: https://www.w3.org/wiki/HTML/Elements/option

My hang-up before was that readonly didn't work with select lists. If select lists, radios, and checkboxes all support the disabled property, it seems like we could work with that somehow. A jQuery solution probably isn't necessary as this is supported directly by the browser.

However, as with any use of disabled, this will prevent the option/checkbox/radio value from being submitted in POST, which makes saving that value more difficult because it doesn't act like other submitted values. The current patch in #18 doesn't address this problem, and you'd end up with data missing from the submission if an option was disabled but also included in the default values list.

DanChadwick’s picture

... you'd end up with data missing from the submission if an option was disabled but also included in the default values list.

Is this an edge case we care about?

Unfortunately we are using "disabled" to mean two different things. A disabled component is one that can be any legal default value, but can't be changed by the user. A "disabled" option is one that is (at least by my way of thinking) and illegal choice. One that is shown for context, but is never a valid value.

Maybe we could use a different word in the UI. "To dim an option, add an exclamation point (!) before the readable option."

I was *not* thinking that the server would notice that the default (or a default, for multi-select) was disabled and bypass the $_POST / $form_state processing for the form API. That sounds like a mess.

I'm not arguing for any one solution or deployment. I just think the issue deserves a decision.

DanChadwick’s picture

Status: Needs review » Needs work

Having second thoughts about the UI.

We would certainly like to use the same mechanism for grid components. I can *easily* imagine wanting to disable one option for one question only. For example:

                  N/A      No      Yes
Competent?        ( )      ( )      ( )
Reliable?         ( )      ( )      ( )
Awesome?          ( )      ( )      ( )
Make job offer?   ---      ( )      ( )

This would suggest a separate list of disabled options, rather than hacking up the names. It would also imply extending the API for dynamic option lists.

For selects, just a list of disabled option keys, like default values: key1, key2, key3
For grids, an optional question prefix: key1, job_offer:na

Liam Morland’s picture

I think this makes sense. I was concerned about adding characters with special meaning to the titles. You never know when this might conflict with something. For example, there is an ethnic group in Africa which is the name of which is spelled in English "ǃKung". Someone making a web site for programmers might want to have a select list with options "A" and "!A".

If options_element was merged with Webform, then that could take care of a more elaborate UI, perhaps a checkbox next to each option allowing that option to be disabled. The difficulty arises when trying to cram too much into the options text field.

rpsu’s picture

I agree with #29. Can we find similar/same approach for UI with all selectable elements? I mean this would cover select options, checkboxes, radios, grid, maybe even optgroups. IMO it would ideally follow #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent. approach.

Would it be possible to extend FAPI with something similar as in #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent., comment 115? And solve non-disableable options issue through that. Single option element would be either a 'return_value'=> 'Text for UI' or something like proposed in #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent. comment #115 patch https://www.drupal.org/files/issues/342316-115-select-options.patch

An associative array containing:
 *   - element: An associative array containing the properties of the element.
 *     Properties used: #title, #value, #options, #multiple, #attributes.

This way each element could have set of options and options_element would be helpful in setting those elements?

$options = array(
  'return_value1' => t('Display Value 1'), 
  'return_value2' => t('Display Value 2'), 
  'return_nonselectable' => array(
    '#title' => t(Non-selectable),
    '#attributes' => array('#disabled' => TRUE)),
  ),
);

I'd be happy to find solution either directly in Webform or using options_element. AFAIK options_element is simple UI improvement tool so I assume backend implementation should be done in Webform.

DanChadwick’s picture

options_elements could be extended to supply additional information about each row. I'm not sure if it today handles option groups, but it certainly could. I could expand and compress to/from a format like key|Human value|attribute1|attribute2, where the only attribute right now would be 'disabled'.

The problem I have with this is that 'disabled' is English. So then we might be back to symbols. Or maybe we don't translate it, requiring other languages to just use 'disabled', which could be noted in the description for the options textarea.

This is why I'm thinking that a better interface might be to split out the disabled list.

Note that whatever FAPI gets into D8 doesn't necessarily affect Webform, at least not through the UI. The callback to generate dynamic lists would ideally use sometthing close to what FAPI uses, but not necessarily.

DanChadwick’s picture

Note that now that grids can have nested select elements, the options for a particular select may omit an undesired option and the grid will leave a blank cell for it.

This means, I think, that we don't have to solve disabled options for the individual questions that are built into a grid because grids can just use select elements. If we want them disabled, rather than omitted, then whatever we solve for select elements would work for grids (via nested selects).

Also related is having titles for the options to give a tool tip. This is making me favor something like 32, with:

safe_key|Human value|attriblute1|attribute2.

attribute1 could be 'disabled'. We require CSS to be in English, so I think this is okay. I'm thinking another could be 'title:"

So we could add titles to grid options (which would show in the header an all internal questions, and for the questions (which should how in the row headers.

jrochate’s picture

The disable trick on #18 doesn't work when Conditionals are being used to show or hide option form fields.

I'm using css class, but I think is preferable this last solution being discussed here.

Please, keep up the good work.

jay.dansand’s picture

This issue hasn't been poked in 2 years, but as it's still open I thought I'd post here.

I needed this functionality for an event registration form, and implemented it as a module. Currently in sandbox, but if people think it could be handy, I can promote it to a full project: Webform Disable Select Options. It has been tested against Webform 7.x-4.x.

jwineichen’s picture

I would definitely use that submodule.

jay.dansand’s picture

@jwineichen and @jrochate Sorry it took me a couple months to get around to it - I've now promoted the project: Webform Disable Select Options.

Note: I solved the conditionals compatibility problem by using a MutationObserver to check for conditionals toggling disabled. If this made it into Webform core, it'd be trivial to store the original disabled state and restore that when conditionally exposing content, and the MutationObserver could go away.

jwineichen’s picture

Thanks so much @jay.dansand!

jrochate’s picture

Awesome! Thanks @jay.dansand.

TLTHades’s picture

This problem can be solved using the module Form Options Attributes

Liam Morland’s picture

Status: Needs work » Fixed

This seems to be solved by the modules mentioned above.

Status: Fixed » Closed (fixed)

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