Under cirumstances not all required fields are validated correctly.

I'm experiencing the same issue, but without Entity Browser, Media Entity and IEF.

I have a content type with a regular Image field and an entity reference field. The node add form can be posted without an image chosen when Automatic Label is activated on the content type, regardless of it's setting (hide label field, prefill or generate if left empty). If I deactivate the Automatic Label the image field is validated again.

One wildcard in my setup is that I have two additional fields that have Field Permissions activated in them. But the image field isn't validated regardless if the user have or haven't got access to edit those two fields.

I will dig deeper to see if I can find the problem since I need to have this solved (or worked around) by next week.

(My versions: Drupal 8.4.3, Automatic Entity Label 8.x-2.1-beta1, Field Permissions 8.x-1.0-beta4)

I think this patch solve the issue

Hi. i was able to reproduce initial issue on 8.x-3.x, but could not reproduce it as in #2.

I reviewed and tested the patch from #3 works as intended. Moving it to RTBC.

It is occurs not only 'entity_reference'-fields. The problem is broader. All required fields not actually validated.

Patch will be attached.

The patch code makes sense. Did not test it though.

I wanted to test this one, but I can't reproduce the issue. I tried reproducing it on 8.x-3.x-dev and tried all Automatic Entity Label settings, but validation seems to work as expected, no matter of the setting I choose. I tried on add and edit forms and also on different browsers.

To reproduce:

• Create content type.
• Set Auto Label to Automatically generate the label if the label field is left empty.
• Add required field.
• Add node. Set title and leave required field empty. Save it.

Node successfully saved.

Tried the steps you wrote @super_romeo, but still no success.

I have created a CT, set auto label to Automatically generate the label if the label field is left empty and added a required field. I have than tried to add a node on which required field is left empty and title is set. Node is not saved and I get an error for the empty required field. Should this field be a specific type maybe?

Probably someone else should give this a try, because I can't seem to reproduce this one.

I understood.

To reproduce:

• Create content type.
• Set Auto Label to Automatically generate the label if the label field is left empty.
• Add required field Geolocation with Google Map widget.
• Add node. Leave title empty and do not set the marker. Save it.

Node successfully saved.

@ #11 - this is a complete different story and reveals that this issue is rather about how Geolocation field is saving its own states and if the system accepts it as "set value" or not, even if you haven't marked a spot yet. Not sure if this 100% belongs to OT of this issue?

Apart from that: thanks at all and +1 for working on this and taking the time to test, report back and clarify.

I have run into this issue as well, in my case with a required entity reference field that happens to use Entity Browser for the widget.

Our node type has auto entity label configured to hide title field and generate title via token patterns.

If I change the field widget for the required entity reference field to core Autocomplete, the required field validation executes fine. If I change the field widget to an already configured Entity Browser, the required field validation is not run. Other fields that are set as required (various including date field widget, checkboxes widget, select form widget) all validate normally. It's only the entity reference field when configured with Entity Browser widget that fails to validate.

If I then change the auto entity label configured to disabled for the content type, the required entity reference field validates as required just fine again, using the Entity Browser field widget.

It appears that the code in auto_entitylabel_validation_constraint_alter() is where things go south:

function auto_entitylabel_validation_constraint_alter(array &$definitions) {
  $definitions['NotNull']['class'] = 'Drupal\auto_entitylabel\Plugin\Validation\EntityLabelNotNullConstraint';
}

If I comment out the alter of the constraint definition, everything work as expected again. If I uncomment out, then my required entity reference field with Entity Browser widget no longer validates. One can only assume that the above constraint alter is too broad and ends up having unintended side effects.

For the time being since this is causing side effects for us, we have worked around this by implementing our own hook_validation_constraint_alter() and reverting the NotNull constraint back to core's constraint.

So I tested this one out and it seems that everything is working correctly from the automatic entity label point. I added an entity reference field with media and image for reference type. Marked the field as required on the basic page, which has set the automatic entity label to "Automatically generate the label and hide the label field". Then created an entity browser with the Upload images as media widget. Everything works. Then tested it with the content entity reference, where entity browser widget was set to view, so created an entity browser view which displays title. And also everything works.
The issue I came across and think it's entity browser related is, when I add media reference entity with image reference type and in the entity browser widget I select the "normal" upload widget, then I get the error of "The entity must be of type media." which is entity browser error not automatic label entity error, as if I comment out the $definitions['NotNull']['class'] = 'Drupal\auto_entitylabel\Plugin\Validation\EntityLabelNotNullConstraint'; I still get the same error.
So maybe if the issue is still present, could somebody post detailed steps to try and reproduce it? Maybe I missed something in my testing. Leaving the status as it is, as I did not test the Geolocation field issue witch was also mentioned in the comments.

I'm experiencing this issue as well. Like others, Entity Browser with Auto Entity Label is the bad combination for me. Here are the steps I just used to reproduce this on simplytest.me:

drupal core 8.9.11
+ auto entity label
+ entity browser

- create view of articles, leave default but add an "entity browser" display, save.
- create entity browser at admin/config/content/entity_browser - call it "article browser" and save with defaults.
- select a "view" widget and under the "select a view" dropdown choose the view we just created. save.
- Add a new content reference field to the "basic page" type that will reference an article. limit 1 value and save.
- set as required, set reference content type to article, save.
- click "manage form display" tab and change the content reference field we just created to "entity browser" widget.
- click the settings cog and select the new entity browser we made earlier. save
- click automatic label tab (still in basic page settings)
- click second option "Automatically generate the label and hide the label field", save.
- create a "basic page", you should see no title field, and a required article reference field.
- just hit save and it should save without requiring the article reference.

Patch in #3 seems to work for me so far - Thanks firass-ziedan. Hope this helps.

I think I'm experiencing this issue with a core image field (not using entity browser, media or anything extra).

Steps to reproduce
- Install Drupal core and enable auto_entitylabel
- Create a new content type and add an image field: Set the field to allowed values to another number greater than 1. ie, 2 or 10.
- Set the auto_entitylabel to "Automatically generate the label and hide the label field" and populate off something such as the author name and
- Create a piece of content, leaving the image field blank

Outcome: The form submits without validating.

If you set the image field to "Unlimited" or "allowed: 1", the validation works as expected.

If you disable auto_entitylabel for the content type, validation works as expected in all scenarios.

Adding the patch at #6 resolves the issue.

I was able to reproduce the issue, tested different scenarios, and confirmed that adding the patch at #6 resolves the problem. Moving this to RTC.