Add validation constraints to contact.settings

This needed ✨ Follow-up for #3324150: allow specifying a prefix for ConfigExistsConstraint, to enable using it for references to config entities Needs review .

But sadly once again, just like both book.settings (see #3422862-3: Add validation constraints to book.settings → ) and filter.settings before it (see 📌 Add validation constraints to filter.settings Fixed and #1932544: Remove all traces of fallback format concept from the (admin) UI → ), this simple config violates the basic rule of simple config: that it cannot depend on other config entities. 😬 Fixing that is out of scope here.

Ah, interesting — I worked to convert the weird integration of editing the contact.settings simple config from within the ContactFormEditForm config entity form to use #config_target (see https://www.drupal.org/node/3373502 → ), but didn't realize that wouldn't work, because #config_target is only available on ConfigFormBase subclasses. So … there's nothing else to do here!

Attached is the patch containing what I did before I realized it cannot work. Only if ✨ [PP-2] Introduce ConfigEntityForm to standardize use of validation constraints for config entities Active adds #config_target support to config entity forms would this be possible to implement.

Legitimate failures:

• MigrateContactSettingsTest (for both D6 & D7)
• ContactStorageTest
• ContactSitewideTest

This is likely because default_form no longer is allowed to be set to '', only to null. That means this needs an update path similar to 📌 [PP-1] Make NodeType config entities fully validatable Needs review .

Clarifying that this is blocked on ✨ Follow-up for #3324150: allow specifying a prefix for ConfigExistsConstraint, to enable using it for references to config entities Needs review .

✨ Follow-up for #3324150: allow specifying a prefix for ConfigExistsConstraint, to enable using it for references to config entities Needs review landed, rebased MR 👍

NW for #5.

Merged in upstream. I still expect this to fail due to #5.

But … I also expect a nice green new CI job thanks to ✨ Add a "Validatable config" tests job to GitLab CI to help core evolve towards 100% validatability Fixed 😄

Yay:
🤩

Details: https://git.drupalcode.org/issue/drupal-3422872/-/jobs/1056803

kunal.sachdev → made their first commit to this issue’s fork.

Thanks for pushing this further! 👍

The updated migration logic/tests are clearly incorrect though. 🙈

See https://git.drupalcode.org/project/drupal/-/merge_requests/6713#note_294465 — \Drupal\contact\Controller\ContactController::contactSitePage()'s logic is the problem.

No more concerns 😊

🚢

Made a minor comment edit and waited for tests - came back green.

Committed to 11.x and backported to 10.3.x

Thanks

larowlan → closed merge request !6713

Automatically closed - issue fixed for 2 weeks with no activity.