Problem/Motivation

When overriding building of contact emails, the "recipients" field is hidden in favor of using Email Policy. However the hidden field is still displayed on the "Contact forms" page (/admin/structure/contact). The same would be true anywhere else that calls ContactForm::getRecipients().

Proposed resolution

2 options:

  • Override ContactFormListBuilder with a derived class that changes buildRow()
  • Override ContactForm with a derived class that changes getRecipients()

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork symfony_mailer-3347378

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

AdamPS created an issue. See original summary.

mingsong’s picture

mingsong
Location 🇦🇺
commented

For a better compatibility with other modules, including core modules, I would suggest keeping the recipients field of a contact form entity identical to the mailer policy's setting.

The reason is that, other module might still rely on that field of a contact form entity. Hiding recipient from "Contact forms" page would cause confusions to other module's users.

adamps’s picture

adamps commented

That's an interesting idea and I see your point.

However it would be a big change to the strategy of this module. There are quite a few email builders that overrides. Currently they have an import function, and after that they ignore the config of the original module, which is hidden in the UI. If this module is uninstalled, the prior original config comes back untouched.

Adding triggers from when a policy is saved to alter original module config would be a big change. The structure of the configuration of this module isn't always identical to the original - for example this module accepts a policy for all contact forms, with an override per form. When the "all" policy is changed we would need to alter all module config except the ones specifically overridden. And the all the override actions would have complex effects.

It would add a lot of code and effort focussed "backwards". It doesn't feel right to me.

mingsong’s picture

mingsong
Location 🇦🇺
commented

Absolutely agreed. It is very complicated.

If we introduce a new token, for example [symfony_mailer:address:to], and then use this token as the default value of a contact form, instead of the hardcode one [site:mail] in the following line.

https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/Plugin/...

This token will be replaced with the correct recipient address via the following line.

https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/MailerH...

If this approach works, it would be way simper and also leave the origin config untouched.

adamps’s picture

adamps commented

'#default_value' is just for newly created contact form entities to allow the form to validate.

There isn't any value to assign for [symfony_mailer:address:to] - the site admin hasn't yet created the mailer policy that would actually contain the to address. Even if we had a value it wouldn't work because the to address could later change.

mingsong’s picture

mingsong
Location 🇦🇺
commented

True.

Regarding the '#default_value', it also affect when the Contact form is edited and saved. Because the form altered by

https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/MailerH...

Agree, it is not idea and won't work for all scenarios.

adamps’s picture

adamps commented

I see it like this. This issue is about when emails for the contact module are overridden, which is optional.

  1. If sites would like to keep everything the same as before then they shouldn't override.
  2. If they override, then some parts of the contact_form entity will no longer be used as they are replaced by Mailer Policy. This is intentional and is one of the goals of this module. Maybe even one day Core will take this change.

AFAICS the contact_form entity isn't used outside of contact module, except in test code.

I still feel that the solution in the IS is correct. It's not complicated😃. Anyway this issue maybe isn't the top priority.

mingsong’s picture

mingsong
Location 🇦🇺
commented

Good point.

Generally speaking, I would suggest that when we alter a form from other modules, such as overriding the '#default_value', we can also modifying the description of that field if it hasn't been hidden. For instance,

  $origin_description = $form[$key]['#description'] ?? '';
  $form[$key]['#default_value'] = $this->token->replace($default);
  $form[$key]['#description'] =  $origin_description . $this->t( ' (This value is managed by Synfony mailer policies below)');
adamps’s picture

adamps commented

Yes I agree - however we only alter the default when the field is hidden

adamps’s picture

adamps commented
Version: 1.x-dev » 2.x-dev
Component: Code » Override

adamps changed the visibility of the branch 3347378-incorrect-information-on to hidden.

adamps’s picture

adamps commented

adamps opened merge request !173

adamps changed the visibility of the branch 2.x to hidden.

  • adamps committed 82ed6c41 on 2.x 
    Issue #3347378 by adamps, mingsong: Incorrect information on "Contact...
adamps’s picture

adamps commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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