Controlled radio field spits a error even if controlling field is not trigged

I'm getting this as well, but haven't been able to track it down yet.

Some more info-- I seem to only be getting this on required conditional radios that don't have a default set. Setting a default seems to fix the problem. Not sure if this really a bug then-- seems like it might be since not having a default is acceptable as part of cck.

marked #848212: Required and conditional fileds combination as a dupe.

yeah, it's definitely not a fix, just a temporary workaround.

I ran into this problem, too, and I've created a patch. This works for me. Check it out.

Doesn't work if controlled field is Hierarchical Select. Anyone experience same issue?

The patch at #6 worked for me in version 6.x-2.0-beta2.
I've a radio field (not required) controlling another radio field (required). When submitting leaving empty the first radio I get "An illegal choice has been detected. Please contact the site administrator conditioal field" error.

This patch solved my problem, suggest to insert in dev...

I can't reproduce this issue in 6.x-2.0-dev. Could anyone provide an export of the content type that gives this error?

subscribe

Here is my form configuration:

The controlling and conditional fields are in one group.

The "An illegal choice" error appears when the controlling field is a radio button and the conditional fields are radio buttons.

The error does not occur when the conditional field is changed to Text Field or Select List.

I tried to export the content type but it is a big file and the server timed out. If anyone wants an export I will try to clone and delete other fields and export, or something.

To reproduce, click "Hide B" then try to submit.

Patch in #6 works fine for me with 6.x-2.0-beta2. Could we get a commit?

The problem is easily reproduced in 6.x-2.x-dev with the content type export I previously posted.

This approach would introduce a security flaw in forms validation where a user could submit a value other than allowed values, so it's not acceptable. I'm not sure there is a way to circumvent the problem without some serious and troublesome hacking of the validation process.

Attached is a patch that limits the danger by removing #needs_validation only on radio widgets without default value. Again, I don't recommend using it for security reasons.

Anyway, I'm setting the priority to normal since there is an easy workaround by setting a default value.

I agree that it's not critical, but I'm not sure I see how it's a security issue as much as a specific use case where an admin should be well aware of the ramifications of this choice.

I have 3 enterprise sites with extensive conditional cck radio fields on many content types (dozens of radio fields) with the specific requirement that radio buttons be required but not have a default value (to force the user to make a conscious selection). Also, setting a default is not a work around in this case since it's specifically excluded from being an acceptable solution.

In any case, I have no problem maintaining this patch for myself, but there may be enough of a user base, inexperienced with patches, that also require this functionality. I'll be curious to see if any one else posts to this thread.

Thanks for the update.

Thanks for reviewing and improving the patch, peterpoe. I don't think setting a default value is a work-around: Sometimes you have fields where you need the user to actively make a selection. If a required radio buttons field has a default value, it is easy for the user to inadvertently submit without actually making a selection.

For instance, if you had a marital status field
( ) Single
( ) Married
( ) Divorced
and the default was "Single", many people would end up inadvertently entering "Single" even if they are married or divorced.

I suppose you could:
1. Add a dummy value like "Dummy".
2. Write a module to hook validation and fail if "Dummy" is submitted.
3. Use hook_form_alter() to hide the "Dummy" radio button so it is not displayed.

That's a heck of a work-around though. :)

Patch in #15 does not seem to work--you get the same "illegal choices" error for radio fields lacking a default value that you get without the patch. Patch in #6 works, but is even more of a security risk, as peterpoe explained.

This is at least a major bug. But actually there are 2 bugs:

1. When a required radios field with no default value is *not* triggered, submitting displays "An illegal choice has been detected. Please contact the site administrator." when it should display nothing.

2. When a required radios field with no default value is triggered, submitting displays "An illegal choice has been detected. Please contact the site administrator." when it should display "FIELDNAME field is required.".

Neither patch at #6 nor patch at #15 seem like good solutions to me (and #15 does not work at all).

Following #17, here is an easier workaround:
1. Edit your controlled radios field
2. Let N/A as default value
3. Check Required
4. In allowed values list, add |Undefined, e.g.

|Undefined
value1|Allowed value 1
value2|Allowed value 2

5. Save. That's it!

Obviously, an extra "Undefined" option will be displayed to user, but with some CSS (a simple display:none;), you can hide it.

I guess there might be some way to integrate this workaround into the module's code.

Committed a more elaborate version of #15 that adds a custom validation function, so invalid values are still filtered out even if #needs_validation is unset.

Tried to test the fix mentioned in #21, but it appears the 6.x-2.x branch is not currently working. After pulling the latest from git, all the controlled fields show up even if not triggered.

Latest dev works good for me. Did you clear your cached data under admin/settings/performance ?

Sorry, user error--the latest 6.x-2.x branch code is indeed working. (The Firefox install on the machine I used appears to have problems. Sometimes the conditional fields will work; other times they won't. It's likely my configuration.)

The 6.x-2.x-dev branch on the Drupal site seems to have gone missing, since I can't seem to find it. Did something happen to it?

If you click on view all releases you should find it.

Here is a direct link.

http://drupal.org/node/648888

Drenton,
Thanks, I looked through there, but just saw the "post date" and not the updated date. Thanks for pointing that out for me.

Tried the workarround in #21 work fine for me.
Before have tried to install the dev version, was a bad experience, I even lose my managed fields tabs in the content type editing form.
Not sure was due to my specific installation or not.

So I stay with the workaround thanks anrikun waiting the correction be commited in the next release.

@jjwhitney thanks, your patch saved my life :)