Fix Required fields to really not be required

I was seeing this behaviour as I was working on the latest patch for #2934226: Better handling for paragraphs module. It looks like problems with the system having difficulties finding the correct form element to render - it would display correctly, but the Javascript would choke later when the form was submitted.

Give the patch from #2934226: Better handling for paragraphs module a try - see if it cleans it up (40% confidence it might work).

Alternately, look at how you're hiding your title. If you're altering '#title' in the form, it may panic like this.

... rats. As soon as I moved to a different node type I hit similar issues.

Mine are ...[0][target_id] and not ...[0][value], but assuming they're similar.

Hmm, mine are being particularly cranky about required fields that I haven't selected (same as @brooke_heaton has described), but only fields that aren't sitting at the root of $form. For example, I'm looking at /node/add/my_content_type, and there are several required fields. But only the fields that are somehow indented (say, by a Field Group, or a Taxonomy Entity Reference multi-select) seem to be balking. Anything that's a plain, normal required textfield seems to not be throwing an error.

I need to fix this, let me see what I can figure out...

The issue is that some of the more complex form elements have $element['#required'] = TRUE set at more than one level of the form. The $element['#required'] = FALSE; in getSelectorForm isn't sufficient to make the element not required.

Worse, it looks like the element selected by findFormElement() is a bit screwy. I have a multi-valued taxonomy that's choosing to add $element['#required'] = FALSE to the ['widget']['add_more'] button, and not to both ['widget'] and ['widget']['0']['target_id'] where it's actially needed.

One way to deal with this is to have findFormElement trimming ['#required'] = TRUE from the form as it traverses downward. That seems to make the problem go away but I can't roll it up as a simple patch - the required code is right in the middle of my #2934226: Better handling for paragraphs module patch and they'd conflict. It's also dancing perilously close to the fix I just made to #2988522: Edit the latest revision instead of default.

Let me roll up this patch at attach it here (I need it too!), under the undertstanding that it conflicts with patches in other tickets and should be rejected and repaired after #2934226: Better handling for paragraphs module is resolved.

Ack, too many colliding tickets. Let me try that again.

Again this includes code from #2934226: Better handling for paragraphs module and #2988522: Edit the latest revision instead of default and needs to be rerolled when those are resolved.

Updated patch to reflect updated code in patch to #2988522: Edit the latest revision instead of default.

Flagging this as "needs work" because the patch depends on other tickets being resolved.

@TrevorBradley, can we have references to the blocking issues here?

I'm experiencing this issue and would like to help testing.

I tried applying the patch in #7 against 2.3 and 2.x-dev and experience other issues (modify field values does not appear as an action).

I assume this is due to the blocking issues.

How should I apply this patch within the context of the blocking issues? Am I doing it right by applying #7 alone against the latest stable/dev version? Or should I apply a combo of patches from the associated issues against a specific version?

For those who are still waiting for this issue to be fixed, a quick workaround is to make all the fields of your entity form optional (Non-mandatory) and make all the fields of referenced entity optional.

Verified this patch does not apply against 2.4... But my referenced patches are all fixed and approved now! Time for me to reroll a new version.

As stated in the original ticket - specifically about a required Title field, this issue appears to be fixed. However, it's still breaking against regular mandatory fields. I've managed to disable #required across the entire form using this patch. Here, I'm using the existing form traversal (using ModifyEntityValues::findFormElement) to wipe out all the #requireds nested in the form.

However, on my site, I'm still seeing required Inline Entity Form (Complex) fields having required set to "required":

<input data-drupal-selector="edit-node-product-field-material-and-composition-form-entity-id" class="form-autocomplete form-text required ui-autocomplete-input" data-autocomplete-path="/entity_reference_autocomplete/taxonomy_term/default%3Ataxonomy_term_starts_with/RMjTQY0iVU2WZkA3XMehZSuGwlAtk1JGj8P3Amm3r1Y" type="text" id="edit-node-product-field-material-and-composition-form-entity-id--cMsFsajJQdM" name="node[product][field_material_and_composition][form][entity_id]" value="" size="60" maxlength="255" required="required" aria-required="true" autocomplete="off">

This is possibly related to a recent update to Inline Entity Form.

Unfortunately, I've got to put this issue aside for a few days. I'm going to upload the work I have to date, but leave this patch as "Needs Work" until I can come up for a fix for Mandatory IEF Forms. Hopefully it will help people bulk edit non IEF Form nodes!

I did manage to figure out how IEF makes fields mandatory, and had added in these lines to my patch in findFormElement:

      // Inline Entity Forms have a strange way of enforcing validation.
      // InlineEntityFormComplex::formElement() uses #element_validate to enforce a required field.
      // If this exists in this form element, disable it.
      if (isset($form[$key]['#element_validate']) && is_array($form[$key]['#element_validate'])) {
        foreach ($form[$key]['#element_validate'] as $element_validate_key => $element_validate) {
          if (is_array($element_validate) && !empty($element_validate[0] && !empty($element_validate[1]))) {
            if ($element_validate[0] == 'Drupal\inline_entity_form\Plugin\Field\FieldWidget\InlineEntityFormComplex' && $element_validate[1] == 'requiredField') {
              unset($form[$key]['#element_validate'][$element_validate_key]);
            }
          }
        }
      }

However, IEF still seems to choke on the field update if I do attempt to update the field.

I then realized I’m making this all far too complex. Views Bulk Edit has it’s nifty bulk_edit form mode. Simple answer: don’t use IEF with Bulk Edit (for now) - just override it for Bulk Edit with an autocomplete (tags style). VBE isn't the time to be creating or crafting on the fly.

With a solution in hand, I’m going to flag my patch as “Needs Review”.

I've tested this further. I'm trying to use Inline Entity Complex forms on Views Bulk Edit to both select and create new values for a bulk edit.

Patch #7 + Views Bulk Edit 2.2 works, even if Views Bulk Operations is upgraded to 3.3 and Inline Entity Form is upgraded to 1.0-rc2
Patch #7 + Views Bulk Edit 2.3 works for things like titles, but doesn't work as described above.
Patch #14 + Views Bulk Edit 2.3 doesn't allow updates on Inline Edit Forms - the values are discarded and Views Bulk Edit saves no value in the field.

I dug a little further and it looks like the $data passed to ModifyEntityValues::submitConfigurationForm is empty for the IEF field. The inline entity form is also misbehaving within the Views Bulk Edit (2.3 only, 2.2 is fine)

Having tested that upgrading Views Bulk Operations or Inline Entity Form alone don't cause the errors, I think I'm going to stick with Views Bulk Edit 2.2 for now on our live site, and continue trying to work on this ticket.

wfm

@douggreen, can you add information which patch did you apply and some testing information? Can you also read #16, where @TrevorBradley says it still needs work?

Using Drupal 8.9.1 and patch from #14 worked for all of my required fields (THANKS!)... except the Date field using date range (datetime_range).

I have a date field using "date range" and that has two values. "value" is start date and "end_value" is the end date.
This patch fixed all required fields and the start date of the date field, however, it does not work on the second "end_value".

An invalid form control with name='node[event][field_date][0][end_value][date]' is not focusable.

I have tried editing the patch to include end date but then that removes the start date and all other required fields.
Any idea how I can keep this patch (since it works) and only add the end value so it also ignores that second value?

Thank you.

UPDATE
Okay so I found a solution if anyone needs the fix on #14 but has the datetime_range module installed and as a required field.

I simply applied this patch #14 and that takes care of that.
But for the "end_value" I simply applied a patch to make the end date optional and then under the field settings, checked the option to make the second date optional.

Here is the page where that patch is found:
https://www.drupal.org/project/drupal/issues/2794481#comment-13598802

I used patch for version 8.9.x and it works perfect.

I experienced the same issue with an address field. The hint in the patch of #2950665 Fetch form view mode dynamically to render to restrict the form fields helped me resolving it.

Patch 14 did nothing for me in VBE 8.x-2.4. It says it found a few elements marked as required, but setting required to false in the patch didn't cause the required errors to go away in the form.

I have media entity type where there are several required fields. One of which is "Asset Type" (taxonomy, select dropdown) and the other is a URL (Link field type with URL and text). When using VBO/VBE to "Modify field values," it does not complain about Asset Type, it only complains about the URLs.

I can make them not required, but that is merely a workaround for the bigger problem at hand. VBE should be able to ignore required fields.

Patch rerolled to apply to the latest dev branche

Setting back to Needs Review since a patch was added after the maintainer required more info.

Duplicate of #2947355: Required field validation error with inline_entity_form?

#24 doesn't work

Removing #required in forms only allows VBE itself form to be submitted - but as soon as field validators kicks in - they produce form required errors anyway.

Tested on commerce product entity.

Patch attached takes another approach.

Instead of trying to set the #required property to FALSE where possible, this patch uses the #limit_validation_errors property to limit the validation to only those fields that were selected to be edited in bulk.

#limit_validation_errors is usually set when the form is initially built, but since we don't know yet which fields the user is going to change, I'm modifying #limit_validation_errors in an #after_build callback during submission (making the value #limit_validation_errors basically dynamic instead of static).

It also disables HTML5 validation on the bulk edit form since that can prevent the form from being submitted due to (non-selected and thus hidden) required fields.

Didn't thoroughly test this, but it works for my (initial) use-case. Would appreciate feedback.

Updated the patch a little to fix the test regarding the revision UI.

Patch in #30 applies and allows me to submit the form, but I'm still having form validation issues with required fields on `paragraphs`. Has anyone been able to get VBE working with `paragraphs` containing required fields?

Thank you!

Views Bulk Edit 8.x-2.6
Views Bulk Operations (VBO) 4.1.2
Drupal core 9.3.12

has this been fixed, i have same problem wiht apply button being frozen...is this patch commited to dev version of the module?

this works I just patched it and the apply button works
when will it be merged in latest release?

Thank you, patch from #30 worked for me as well. I needed to update Product entities in Drupal Commerce and had a ton of "not focusable" elements in the form. Now it works.

Same here. #30 fixed the issue with Drupal Commerce products. Thanks!

I can confirm patch in #30 solves the issue for me. I don't experience the problems with required paragraph fields as stated in #31, although my content type contains such fields.

Views Bulk Edit 8.x-2.8
Drupal 9.4.8

Patch #29 doesn't work with Drupal Commerce. It's still asking for variations SKU and Price.

@mjgruta, go into the product types configurations and check the "Allow more than one variation" checkbox. That will move the SKU and Variant Title off of the primary product entity form and allow you to perform a bulk edit.

There's also a workaround you can use in a pinch that works if any field doesn't play well with the patch.

Select the SKU and Price fields and enter a value in for each field. Now uncheck those fields as fields you want to edit. Whatever you just entered will not be applied. They'll remain filled in so you'll be able to submit the form, but the values will be ignored.

HI,

Patch #29 allows me to at least post the form but its still giving me an issue with a specific required field.

The field I want to change (Company) and the field which tosses the error (Review Author) are both entity reference fields. (Note: I do no want to change the Review Author field.). I have other required fields which are not throwing errors.

Thanks,
Eric

@aitala: From your screenshot, one could assume that you ticked "Review Author" before submitting the form. Even if I don't draw that conclusion, I would like to point out that the tick must of course not be set for required fields whose values you don't want to change.

HI,

I did not tick the 'Review Author' box before I submitted the form.

I ticked it which revealed the "Review Author (value 1) field required." notice otherwise all you see is the '1 error has been found: Review Author (value 1)' notice with no explanation. The only value I am trying to change is the Company field.

Eric

Patch #30 is not working for me too. Have a simple content type with required image field, but trying to bulk update a boolean field, getting error "Image field is required.".

Patch #30 did not solve the problem, it allows the form to be sent but title and URL are still required. Any updates on this one?

I updated the patch to work for nested form elements, change the required values to false, and remove validateRequired callbacks.
Please review the new patch.

Patch #45 is working in my case.

Patch #45 is working in my case.

Patch #45 isn't working for me when Address field has some required fields.

If I make them optional, then the updates for other fields go through, even when the Alt field of an image field is kept as Required.

Doesnt work with nested paragraph required fields.

Patch #45 doesn't work for me. It gives me this error:

TypeError: array_filter(): Argument #1 ($array) must be of type array, null given in array_filter() (line 436 of modules/contrib/views_bulk_edit/src/Form/BulkEditFormTrait.php).

The problem that triggers the error is that the values are no longer in the $form_state->getValues() but I do find them in the input.

$field_data = $form_state->getValue([$entity_type_id, $bundle]);

So if I replace this line with this, it works but I don't think this is a good solution.

$field_data = $form_state->getValue([$entity_type_id, $bundle]);
        if (!isset($field_data['_field_selector'])) {
          $input_data = $form_state->getUserInput();
          $field_data = $input_data[$entity_type_id][$bundle];
        }

For me patch #29 works, except for some entity reference fields that are still required. I added some code to the patch to fix my use-case.

Provided an update which uses the States API to switch the #required fields off/on based on whether the field was ticked or not. And recursively disables the #required and #access to fields which the user is uninterested in editing.

It should also work with various other field widgets such as Paragraphs or Media Library.

I believe the initial novalidate approach isn't advisable since you lose all client-side validations.

Addressed a flaw in logic where it's possible to accidentally flag a field as "required" as long as it had a #element_validate or #validate property.

Addressed an oversight in the #56 patch.

Thank you this is working with me

Patch #57 worked for me

I was getting two error messages like "An invalid form control with name ... is not focusable". The patch in #57 fixes one of them. The other message remains, causing the VBO action to fail. The error message that remains is about a required field that is part of a paragraph.

Agree with @Liam mortland patch #57 works for me too for the required field focusabled.

Checked on Drupal 10.3.5.
Best regards and thanks.

Patch #57 is working for me

Since it was tested by several people, I've moved it to reviewed and tested.
Best

Dear community, I'm going to add a piece of code in order to cover the fields provided by inline entity form.

Best regards

Hi all, I added the code, this can be reviewed.
Many thanks in advance.

#66 solved the issue in my case.

#66 works like a charm over 2.9.0, thanks a lot !
Uplodaed patch version of MR20 for convenience.
+1 for RTBC

I had been using #57, but it wasn't working anymore, so I checked #68, and it works.
Version 8.x-2.9

I couldn't update the MR to go into 3.x branch - so I've pushed a new branch 3024419-fix-required-fields-3.x

If somebody is able to update the MR I'll can push my work there and hide by new branch

Changes were just rebasing against 3.x and added test coverage for the use case I hit which is with a multi-value entity reference field.

Test coverage passed: https://git.drupalcode.org/issue/views_bulk_edit-3024419/-/jobs/4910511

Test only change shows issue on 3.x: https://git.drupalcode.org/issue/views_bulk_edit-3024419/-/jobs/4910512

I'm not sure if we want this as its own test, but since its just being added to the entity and not actually interacted with which is the issue I just expanded the current test. Happy to take maintainers direction here.

Also shows 3 PHPCS issues from the original changes / MR to be addressed - setting to needs work based on that.

#68 for me won't work. I have scenario where:
1. I selected 2 entities
2. I can update one of them, as there will be no errors. For the other one I know there will be error.
3. #68 skips all updates, while on #52 one item is updated (as expected).

There is small bug in #52 (php error, when you try to submit, but nothing selected to be updated), I improved it in #74.

One more small improvement to #74.

I just tested the patch in #75 but I am getting tripped up by an address field with required sub components.

Address field uses sub components, which may individually be required, such as "administrative_area", etc.

I think the general approach of the patch is good, but I think maybe it should test for subcomponents, and loop over them, maybe recursively, and mark each as not required.

I was also thinking of a different approach, maybe it's not a great idea, or complex to implement, but what if instead of loading all the possible fields for each selected bundle (e.g. for entities selected of different bundles), it only loads the selected fields via ajax? This way, if I don't want to edit the address field, the field won't exist in the bulk form. That seems like it might be cleaner than trying to dig into all the possible ways different fields are structured. Maybe there are challenges with that approach I haven't considered?

Unfortunately, I probably don't have time to do anything with the Ajax option, so I am just going to see if I can do something quick and dirty to loop over the sub components. It probably won't fix every possible field, but address field is pretty popular, so at least fixing that would be a step forward.

Tried out the 3.x version from #72 and it seems ok (I don't have sub elements to worry about like #77)

Here it is in patch form for convenience.

I've tried @darvanen's patch on #78 and it works on my different environments.

Is the patch in #78 from one of the merge requests? If so, which one?

Yes, it’s MR42

There have been reports of bugs, I don’t think we can really call this RTBC.

@darvanen, thanks for correcting it.

I agree this is a major issue, which partially makes the module unusable. Would be great if we could get further reviews.

Does this also fix #3449641: Cannot bulk edit nodes with a required date range field?

We please need tests to ensure this works as expected - now an in the future.

Confirming patch in #78 resolved issues bulk saving content with a required Media field in our environment. I have not tested other scenarios.