When activating a dependency that changes the required state of a field, required fields are not respected and the entity can be saved without values.


I cannot reproduce this. Can you detail the field and widget types used, and the dependency settings?

I am using two fields:
dependent: entity reference - select list (required)
dependent: text list - selection fields (required)

when I do dependence for the bound field be hidden, it is hidden, but when it is displayed can be saved without value.
I even another rule to make it required and shows two asterisks next to the field, but still require vacuum value and saved

new15.4 KB
new14.11 KB
new12.81 KB
new11.28 KB

I have same problem
I have 2 fields either of the filed is required,settings
Filed_1, and Field_2 or visible when field_a has value=1
field_1 is required if field_2 has value=0
filed_2 is required if field_1 has value=0
When is save without selecting either one the content is saved without triggering the dependency
Also an error message "field_1 or Field_2 is required " is required
please see attached png files, the operation is complete after screen4 but if i save at screen2 stage it allows to save

Priority:Normal» Major

any help??

Priority:Major» Critical

It's really important able to use this module in user entities types.

I am also dealing with such a problem.

I have a select list and 3 text fields. All of them are visible. If you select any value in the select list the text fields become required.
But the user can hit save without inputting any values to the boxes.

The weird thing is that I would sworn that it was working a while ago. I am looking to see if any new modules may have caused this but so far no luck.

Ok, I am using the 7.x-3.x-dev version that I believe was released on Tue, 13 Sep 2011 00:13:51 GMT
In that version when you go add a "required" dependecy there is nothing more than the configuration.

Now in the last version I see a lot things where added along whith this informative text:
The Javascript form state that is applied to the dependent field when the condition is met. Note: this has no effect on server-side logic and validation.

That means that the only thing that this does is add just the asterisk. Nothing else. Correct?
So you could say that this is working as designed. I am still curious though as I remember testing that feature before adding it. I will try to use my old version on a clean drupal installation and come back with the results.

EDIT: Still no luck
Some similar issues:
#1372284: Required field indicated but not enforced
#1412538: Dependee required when dependent checked rule is not enforced on profile

Status:Active» Needs review
new2.79 KB

It wasn't fun, but I made a patch for this. It needs to be reviewed, because I'm not sure what side effects will be from changing:

// Check if this field's dependencies were triggered.
-  if (conditional_fields_evaluate_dependencies($dependent, $form, $form_state)) {
-    return;
$triggered = conditional_fields_evaluate_dependencies($dependent, $form, $form_state);

Any thoughts, comments are welcome :)

Patch not working for me.

I have several select boxes that depend on one checkbox. This means if the checkbox 'foo' is checked, 4 other select boxes are required. I see the required marker is shown next to the select boxes, but the requirement is not enforced on save. These select boxes have a value of _none, but the form is saved without setting them to any other value. Additional I have a checkbox in the same form that is required, when 'foo' checkbox is checked and a value of a select box is 'bar'. The selectboxes are all core widget type Select list.

None of this conditions work. I can always save without fulfilling the requirements. The module is totally useless. No idea why it's installed on 10K servers.

@hass: I agree that required fields should not just be indicated, but rather enforced, see the other issue: #1372284: Required field indicated but not enforced, and I also agree that this is a very big problem, because this is one of the module's main tasks.
But instead of simply calling this module useless and cr@p, you could rather help the developer(s) find out the source of the problem, and write a useful patch to be able to mark this issue as resolved and help many site maintainers too.
By the way, this module is useful for other tasks too (e.g. simply toggling the visibility of some fields according to some conditions), its task is not just the one you need it for (enforcing required fields to be filled out). BUT you're right that this issue still remains critical.

Priority:Critical» Major

I've marked two other discussions as duplicates of this one:
#1372284: Required field indicated but not enforced
#1412538: Dependee required when dependent checked rule is not enforced on profile

I'm also changing the priority back to "major." The priority flag isn't meant to be used as a bump if your issue is being ignored. Please see https://drupal.org/node/45111. I agree that this issue definitely deserves major priority; it's an important function that does not work, and has received a lot of discussion and multiple patches. Clearly there are a lot of people who think this is important.

I'm going to review the patch in #8 when I have a chance.

Status:Needs review» Needs work

I'm afraid the patch doesn't work for me either.

I have a workaround. I added a custom module to my own site with the following code:

function first_node_validate($form, &$form_state){
    if ((strpos('incident', $form->type) !== false)) { // Check the content type
        if (($_REQUEST['field_incident_type']['und'][5]) // Check the dependee field
             && (!$_REQUEST['field_incident_security_action']['und'][0]['value'])){ // Check the dependent field
            form_set_error('field_incident_security_action','You must specify a <em>Security Action</em> on the Security tab.');
            $errors = drupal_get_messages();
            foreach ($errors as $type => $id) {
                foreach ($id as $message){
                    // Loop through individual messages, looking for ones to remove or replace
                    if (test_for_invalid_error($message)===FALSE){
                    } elseif (test_for_invalid_error($message)!==TRUE){
                        drupal_set_message(test_for_invalid_error($message), $type);

It checks for the specific content type, checks to see if the "dependee" field is set, then checks to see if the dependent field is empty. If it is, then it returns an error.

The problem is this is a "one off" solution that only works for a pre-defined content type with a pre-defined field. But I'm hoping someone can take this logic and apply it to a more general solution, and maybe even a patch!

Issue summary:View changes
Priority:Major» Critical
Status:Needs work» Active

Still busted. I looked at this module last year for a possible solution, but I see this specific problem is still unsolved.

Under no circumstance can I make the module respect the required status of the text fields. Tried setting the dependency on a widget value or on a regular expression. Tried with the target fields set as required or optional. Tried with the dependency state switching between option and required. Tried setting the dependency based on checkboxes and radio buttons. Tried setting dependencies on whether the field is empty or filled. Tried it all.

I can always save the node with no value in the conditionally required fields. The check against the required field state is jacked across the whole module.

If you want to reproduce this, set this up:

Dependee field:
List (text) field with values A and B

Dependent fields:
Text Field A
Text Field B

When List field reads A, make Text Field A required.
When List field reads B, make Text Field B required.

I'm advocating that this is a critical bug. I say it's critical because the feature says it can conditionally set the required state of a field and it just can't. There are no working patches for this, either.

Title:Required field is saved without content in user fields.Conditionally required fields are not required

Oh, and a fancy new title that describes the broad impact of this bug.

I have found a bug with the form_set_error statement, that was causing validation to fail. I believe this patch will work in most cases.

You might have a great patch there, but it doesn't address this issue. Applied to 7.x-3.x-dev and the conditionally required fields are still not enforced as required. The little red asterisk still suggests the fields are switched to required, but they are not enforced.

I'm applying this to the non dev branch, and it gives a form error when you try to checkout, maybe you could install devel and come back here with the value of the the $error_key variable and the name attribute of your required field. They should match for form_set_error to trigger.

@arosboro: I'm trying to get conditionally required fields to enforce their required status, but I can't test that on the current recommended release because conditional fields do not store values (this old thing: https://drupal.org/node/1542706).

The current dev release can store values. Can we get a patch against that one?

On a side note, my specific goal of setting fields as both required and visible based on the value of another field can be reached with this module: https://drupal.org/project/field-conditional-state

But it can't be reached with this rewrite of the same module because of unstable code (so far): https://drupal.org/project/field_conditional_state

Note the difference in underscores and dashes in the URL.

Not jumping ship on this issue, though. I prefer to use this module because of the higher usage among the Drupal community.

subscribing to issue

So looks to me like the patch in #18 gets us almost there. The issue is that the check for:

          if (empty($input_state)) {
            form_set_error($error_key, t('The !title field is required', array('!title' => $dependent['#title'])));

That $input_state variable is not just a string but an array with the structure $array[0]['value'] for a standard text field. This structure changes with fields such as a link field though and becomes $array[0]['url']. We probably need to add some logic to see what the field type is and return that. No error is reported because $input_state is not empty so it doesn't set the error. We need to be checking the value of that or whatever that final attribute is.