Entity is not validated prior to being saved

Going further on the patch in #4:

Views_bulk_operations expects $result['message'] to be a MarkupInterface. I changed the patch for this and added the type "error" so the messages get the correct status.

Expanded the patch to limit validation errors to only the ones that the user is able to edit, consistent with content entity forms (https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Core/Entity/ContentEntityForm.php?ref_type=heads#L212)

A small improvement in that the field label is nog also mentioned in the error message, which makes it easier for the user to know which field is causing the error message. As mentioned before, the error reporting is still very much barebones and I expect the work done in #1327632: Support action specific status message reporting. → could help us here.

@rp7 could you turn this into a MR?

Furthermore I' unsure if it should't allow to opt-out. Perhaps adding a setting "Validate entity" which is prechecked, could make sense?

Based on #10

Furtermore this should have a test added.

Implemented the validate method that does the validation for the entity before submit to be able to set errors to bulk form fields. Previous patch just avoided errors and there was no validation errors shown to user.
Also added a test case that checks node save with empty title as right now it results in WSOD.

Hi @anybody,
I don't see point in disabling entity validation.
What the test you imagine for it would be? i.e. if enabled - we have proper validation errors on form and if disabled - WSOD?
Right now I feel like it's important step in saving entity that is being missed, which is a bug that may result in WSOD in certain scenarios

#14 worked for my case. We have a multi-value field that allows a maximum of 2 values. Previously, you could add as many values as you want -- the values would not save, nor would an error be thrown.

After applying a patch from #14, user gets an error when >2 values are chosen.

MR has a merge conflict that needs to be resolved.

Furthermore, as this is a complex change, needs community review.

@anybody fixed merge conflict, please have a look.
sure, I understand your concerns. anything I can do to help this process?

@sickess29

Previous patch just avoided errors and there was no validation errors shown to user.

That's surprising. This patch has been in use for about a year, in a heavily used project of ours - we didn't get any complaints so far.

We did spot an issue with it with in combination with a custom field widget we wrote. Adjusted the patch a little to make it more robust.

Nevertheless, I'm all up for continuing with the work done in the MR - although I couldn't get it to work in my first tests. Will need more time to investigate.