Field Validation doesn't seem to respect detecting a null or an empty string as part of a regexp.

[MarkBurvs]

Describe the Bug

I’m trying to add basic validation to an input field where I want the user to enter either a valid email address, or nothing at all.

I’m using regex and in theory this should work: (^$|^.@...*$), (it works as expected on https://regex101.com), only it doesn’t allow the user to delete an email that was previously entered:

After deleting a previously saved value:

The only way I can get the desired behaviour is by creating an “Or” group, but that gives a double error message when the user enters anything wrong which is ugly and confusing:

Had a short discussion on the Discord about this:
https://discord.com/channels/725371605378924594/1151320093565927504/1209480440944005130

To Reproduce

Create a text input field called "email" within a collection.
Ensure the field allows a NULL value.
Add the following regexp validation rule to detect a correctly formatted email OR an empty string: (^$|^.@...*$)
Go to the Content section, create an item and enter a valid email into the "email" field.
Save.
Value should be saved correctly.
Clear the email field again so it is empty.
Save again.
Validation will fail. Expected result is that it should accept an empty field

Note:
You can test any of the following Regexp alternatives on https://regex101.com and observe that they do correctly match against an empty string as well as an email address, but try them in Directus, and they will fail when the field is empty:
(^$|^.*@.*\..*$)
^(.*@.*)?$
(^NULL$|^.*@.*\..*$)

Directus Version

v10.9.2

Hosting Strategy

Self-Hosted (Docker Image)

[hanneskuettner]

I would indeed not expect a RegExp which is intended to match a string after all to match the value null.
You can circumvent this be setting "Cleared Value" to "Save as empty string" in the interface configuration, ensuring that the value is at least always an empty string. With your regex and this will however encounter an error, that is tracked in #22394.

I will leave this issue open as it's correct solution relies on #22394 to be fixed.