Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contact Form: email recipient field does not correctly handle other users editing a page with a form #40108

Open
jeherve opened this issue Nov 8, 2024 · 1 comment
Labels
[Block] Contact Form Form block (also see Contact Form label) [Feature] Contact Form [Feature] Forms Blocks Blocks designed to streamline user input and engagement, such as contact, newsletter sign-ups, etc. [Platform] Atomic [Platform] Simple [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Pri] Low [Status] Needs Design Triaged [Type] Bug When a feature is broken and / or not performing as intended

Comments

@jeherve
Copy link
Member

jeherve commented Nov 8, 2024

Impacted plugin

Jetpack

Quick summary

Jetpack's Contact Form sends an email notification for each form to the post author by default. That can be changed for each contact form individually, by setting a custom to value.

In the block editor, the recipient email field displays the current user's email address by default, and when saving an updated form, the to value is not updated if the field value matches the default value. It consequently creates an issue when someone other than the post author wants to update that value to their own email address ; their change is not saved because the value they entered matches the default email field value (the current email address).

The only workaround in this scenario is to enter 2 email addresses, since the field value then does not match the default.

Steps to reproduce

Note

Start with a site where you have 2 registered users: the main admin (email address [email protected]) and an editor (email address [email protected]).

  1. Log in as the admin, install, activate, and connect Jetpack to WordPress.com.
  2. Go to Pages > Add New
  3. Insert a Form block on the page.
  4. Publish the page.
    • At that point, if someone submits a form on that page, an email is sent to the page author's email address, [email protected].
  5. Log out of the site.
  6. Log back in with the editor's account.
  7. Go to Pages > All Pages
  8. Open the page containing the form in the block editor.
  9. Click on one of the form block elements.
  10. Click to get to the parent block, the contact form block.
  11. Check the block sidebar: you will find the "Email address to send to" setting.
  12. At this point, let's say you make some changes to the page, and save your changes.

A clear and concise description of what you expected to happen.

Since the form settings indicated [email protected] when I hit save, I would expect that to be the new recipient email address value from now on.

What actually happened

If I refresh the page, and then view the code editor view of the block editor, I do not see any to block attribute saved for the contact form block. The form still uses the default recipient email address, the page author email address, [email protected].

Impact

Some (< 50%)

Available workarounds?

No but the platform is still usable

If the above answer is "Yes...", outline the workaround.

No response

Platform (Simple and/or Atomic)

Simple, Atomic, Self-hosted

Logs or notes

This was originally reported and discussed here: p9F6qB-gom-p2

@jeherve jeherve added [Block] Contact Form Form block (also see Contact Form label) [Feature] Contact Form [Feature] Forms Blocks Blocks designed to streamline user input and engagement, such as contact, newsletter sign-ups, etc. [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Pri] Low [Type] Bug When a feature is broken and / or not performing as intended Triaged labels Nov 8, 2024
@jeherve
Copy link
Member Author

jeherve commented Nov 8, 2024

At this point, I think the problem doesn't necessarily lie in the default value (the post author's email address). The problem seems to be more with the block settings interface.

Image

  • The interface should reflect the reality (where the emails will be sent).
  • Any logged in user able to edit the page with the form should be able to modify the form so forms are sent to their own email address.
  • The interface should not display the current user's email address in that field when that's not where emails will be sent.

What should the interface display then? Should it always display the reality (where the emails will be sent), meaning that when no value is provided, it displays the post author's email address?

Displaying the reality feels like a good idea overall, except when we consider non-admin roles.

Indeed, if we were to display email addresses in that field, an editor could then have access to another user's email address by viewing a page that other user created with a form block.

That may be considered private information. Core seems to consider this as information the user should not have, since wp.data.select( 'core' ).getUser( 1 ); only returns results for your own user ID when you are an editor.

What should we consequently display in that field, for admins, and for editors?

Maybe editors should not see that email address when the form was created by another user on the site?
What should they see instead?

@Automattic/jetpack-design I would be curious to have your take on this? What do you think should be the best UX in this scenario?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Contact Form Form block (also see Contact Form label) [Feature] Contact Form [Feature] Forms Blocks Blocks designed to streamline user input and engagement, such as contact, newsletter sign-ups, etc. [Platform] Atomic [Platform] Simple [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Pri] Low [Status] Needs Design Triaged [Type] Bug When a feature is broken and / or not performing as intended
Projects
Development

No branches or pull requests

1 participant