Add validation constraints to system.mail

Seems like good validation to me.

Committed and pushed 93682028b4 to 11.x and f12a516b4f to 10.3.x. Thanks!

I have to disagree with #5. 😅🙈

This marked system.mail as fully validatable, but it did not change:

    interface:
      type: sequence
      label: 'Interfaces'
      sequence:
        type: string
        label: 'Interface'

… meaning literally any string is accepted, whereas AFAICT it must be a valid @Mail plugin ID? See \Drupal\Core\Mail\MailManager::getInstance().

Similarly, mailer_dsn's scheme and host should probably also be validated but currently aren't.

The key-value pairs under mailer_dsn are trickier/more questionable though, but the mail interfaces are a clear omission.

@Wim Leers great points. Reverted.

Thanks 🙏

For #9 📌 Add validation constraints to system.mail Needs work we already have a constraint

        constraints:
          PluginExists:
            manager: plugin.manager.mail
            interface: 'Drupal\Core\Mail\MailInterface'

to check if the plugin name is valid.

#16: indeed, PluginExists is what you want.

Most importantly: you set this to but I see no new commits? 😅

Discussed with Wim and we were looking at https://symfony.com/doc/current/reference/constraints/AtLeastOneOf.html, as hostname could be a hostname, a ipv4 or a ipv6. After some pairing we figured out that using composite constraints might be complex and could be deferred to a follow-up, as it's not very common to use a IP for a mail server hostname.

However, back at home just discovered the Symfony "Hostname" validator will consider "default" as an invalid one, and that's our default for e.g. when using sendmail, so we really need to figure this out here.

Gave it a try and I think I ended up in the same place I ended up on Wim's computer.

Created https://git.drupalcode.org/issue/drupal-3440975/-/merge_requests/1/diffs for not polluting the original MR. I got stuck when in some place we are expecting typed data instead of the underlying value (or the opposite). Might be easier if we just extend from the symfony validators (as Regex does already), but definitely not as clean :-/

Oops, did some work in parallel on system.mail.mailer_dsn over in 📌 Tighten config validation schema of system.mail mailer_dsn Fixed .

@WimLeers this should probably closed as duplicated, but do you think is worth opening another issue for trying to reuse the symfony validators OOTB. specially for those like AtLeastOneOf?

Nice, 📌 Tighten config validation schema of system.mail mailer_dsn Fixed landed while I was on vacation, so … I agree this can be closed.

I do think it would be superb to create a new issue for adopting AtLeastOneOf! (I lost track of it after pairing with you on getting that to work at DrupalCon Portland, @penyaskito 🙈 — been too occupied with https://wimleers.com/tags/experience-builder.)

Could you open that? 🙏 And perhaps share/describe what the challenges are in adopting that?

Follow-up: 📌 Remove the restriction from RecursiveContextualValidator that prevents using custom groups. Needs review .

I also tried to use AltLeastOneOf constraint in 📌 Add validation constraints to core.menu.schema.yml Needs work and I have mentioned the problems I faced in https://www.drupal.org/project/drupal/issues/3441434#comment-15686742 📌 Add validation constraints to core.menu.schema.yml Needs work .

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.