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!
Comments
Comment #1
quicksketchThis won't be implemented because the property used for "disabling" (which is actually "readonly") doesn't work on select lists, radios, or checkboxes.
Comment #2
tahiticlic CreditAttribution: tahiticlic commentedHi,
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
Comment #3
dunecat CreditAttribution: dunecat commentedHi 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
Comment #4
escoles CreditAttribution: escoles commentedAnother 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.
Comment #5
escoles CreditAttribution: escoles commentedAsking for reconsideration on this. 'Disabled' is valid HTML5 and there are legitimate use-cases.
Comment #6
Hakaku CreditAttribution: Hakaku commentedI agree with escoles. His use-case example is precisely what I'm looking for.
Comment #7
rpsuI 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
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?
Comment #8
DanChadwick CreditAttribution: DanChadwick commentedIf 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.
Comment #9
MrPeanut CreditAttribution: MrPeanut commented@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.
Comment #10
rpsuI 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
Comment #13
rpsuOh, forgot: patch covers only listboxes, not checkbox or radio lists.
Comment #15
rpsuThis patch handles lists, checkboxes and radios effectively replacing patch in #10
Comment #16
rpsuComment #18
rpsuTrying again to pass tests.
Comment #19
RaulMuroc CreditAttribution: RaulMuroc commentedPatch in #18 breaks the solution applied here for the webform conditional. :S without the page the solution for webform conditionals works like a charm.
Comment #20
DanChadwick CreditAttribution: DanChadwick commentedRe #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.
Comment #21
RaulMuroc CreditAttribution: RaulMuroc commentedYou 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.
Comment #22
dasjoRaul, 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
Comment #23
RaulMuroc CreditAttribution: RaulMuroc commented@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).
Comment #24
DanChadwick CreditAttribution: DanChadwick commentedThis 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
User interface
Deployment options
Reference: D8 core issue: #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent..
Comment #25
quicksketchDid 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.
Comment #26
DanChadwick CreditAttribution: DanChadwick commented@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.
Comment #27
quicksketchOh... I didn't realize that
disabled
works on select list<option>
elements: https://www.w3.org/wiki/HTML/Elements/optionMy hang-up before was that
readonly
didn't work with select lists. If select lists, radios, and checkboxes all support thedisabled
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.Comment #28
DanChadwick CreditAttribution: DanChadwick commentedIs 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.
Comment #29
DanChadwick CreditAttribution: DanChadwick commentedHaving 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:
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
Comment #30
Liam MorlandI 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.
Comment #31
rpsuI 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.patchThis way each element could have set of options and options_element would be helpful in setting those elements?
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.
Comment #32
DanChadwick CreditAttribution: DanChadwick commentedoptions_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.
Comment #33
DanChadwick CreditAttribution: DanChadwick commentedNote 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.
Comment #34
jrochate CreditAttribution: jrochate commentedThe 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.
Comment #35
jay.dansand CreditAttribution: jay.dansand commentedThis 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.
Comment #36
jwineichen CreditAttribution: jwineichen commentedI would definitely use that submodule.
Comment #37
jay.dansand CreditAttribution: jay.dansand commented@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 togglingdisabled
. If this made it into Webform core, it'd be trivial to store the originaldisabled
state and restore that when conditionally exposing content, and theMutationObserver
could go away.Comment #38
jwineichen CreditAttribution: jwineichen commentedThanks so much @jay.dansand!
Comment #39
jrochate CreditAttribution: jrochate commentedAwesome! Thanks @jay.dansand.
Comment #40
TLTHades CreditAttribution: TLTHades commentedThis problem can be solved using the module Form Options Attributes
Comment #41
Liam MorlandThis seems to be solved by the modules mentioned above.