Problem/Motivation

At /admin/config/people/accounts, it is not documented anywhere in the UI that clearing the body field of any account email template will disable that email from being sent entirely. This is a useful feature, but it is invisible to administrators who may either accidentally suppress emails or never discover the capability exists.

Steps to reproduce

  1. Navigate to /admin/config/people/accounts.
  2. Scroll to the Emails section.
  3. Observe that no text exists to indicate what an empty body field does.

Proposed resolution

Add a #description to the $form['email'] vertical tabs container in AccountSettingsForm::buildForm() to inform administrators of this behavior:

$form['email'] = [
  '#type' => 'vertical_tabs',
  '#title' => $this->t('Emails'),
  '#description' => $this->t('Removing all text from the body of an email will disable that email from being sent.'),
];

Remaining tasks

  1. Review and agree on the wording of the hint text.
  2. Confirm the description renders correctly beneath the Emails heading in the UI.
  3. Review and commit.

User interface changes

A single line of descriptive text is added beneath the Emails vertical tabs heading on /admin/config/people/accounts. No other UI elements are added, removed, or changed.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

The account email settings page (/admin/config/people/accounts) now displays a note informing administrators that removing all text from an email body field will disable that email from being sent.

CommentFileSizeAuthor
#12 Password recovery.png323.13 KBchris matthews
#12 Account canceled.png249.66 KBchris matthews
#12 Account cancellation confirmation.png241.72 KBchris matthews
#12 Account blocked.png253.34 KBchris matthews
#12 Account activation.png387.07 KBchris matthews
#12 Welcome (no approval required).png348.56 KBchris matthews
#12 Admin (user awaiting approval).png245.2 KBchris matthews
#12 Welcome (awaiting approval).png296.63 KBchris matthews
#12 Welcome (new user created by administrator).png350.39 KBchris matthews
#11 invisible_body.jpg70.53 KBrkoller
#11 visible_body.jpg128.77 KBrkoller
#2 3498765-2-add-email-body-empty-hint.patch552 byteschris matthews

Issue fork drupal-3580795

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

chris matthews created an issue. See original summary.

chris matthews’s picture

chris matthews commented
StatusFileSize
new 3498765-2-add-email-body-empty-hint.patch552 bytes

chris matthews opened merge request !15168

nicxvan’s picture

nicxvan commented

I think a screenshot would help and I bet the ux team will have some feedback.

I think it's a great idea!

chris matthews’s picture

chris matthews commented
Version: main » 11.3.x-dev
Issue tags: +Needs usability review
mtift’s picture

mtift
he/him
Primary language English
Location Minnesota, USA
commented
Status: Active » Reviewed & tested by the community

Code looks good to me. The message text makes sense.

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

i think the MR needs to be against the main branch (currently equal to 12.x) and the changes get then be cherry picked against previous versions.

nicxvan’s picture

nicxvan commented
Version: 11.3.x-dev » main

Yes and we need a screenshot for interface changes

nicxvan’s picture

nicxvan commented
Status: Reviewed & tested by the community » Needs work
rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

and i can put the issue on the short list for the meetings on fridays. not 100% sure we will get to it already this friday cuz the issue we've discussed the last two weeks is not completely finished but this issue is rather brief so odds are high that we will be able to discuss it either already this friday or otherwise friday next week.

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented
StatusFileSize
new visible_body.jpg128.77 KB
new invisible_body.jpg70.53 KB

Usability review

We discussed this issue for the first time at #3581812: Drupal Usability Meeting 2026-04-03. The link to the recording: https://youtu.be/LyBy7cDksSc?t=1400&si=Ixk35BW5CIYs_v1P . The attendees at the usability meeting were @nicxvan, @rkoller, @simohell, and @worldlinemine.

Our discussion was based on the latest state of MR15168. In general adding the information contained in the description is a good thing, we've only noticed a few noteworthy details:

Visually there is a disconnect between the description and the body field it refers to. Instead of being left aligned to the body field within the content area of the active vertical tab the description is left aligned to the vertical tabs itself - through that shift to the left underneath the block of vertical tabs it is not necessarily clear to what the description refers / belongs to or if the description is getting noticed at all. Plus, depending on the availability and height of the body field within the content area of the active vertical tab, there could also be a rather large gap between the last vertical tab and the description:

vertical tabs for the different emails in the account settings with welcome no approval required as the active tab in the default_admin theme

Or the description is shown in close proximity even when there is no enabled visible body field available for the active vertical tab.

vertical tabs for the different emails in the account settings with account cancled as the active tab in the default admin theme

So in case the user notices the description underneath and considers it relevant in the context of the vertical tabs and or body field it is a cognitively/visually demanding task switching the focus back and forth from the body field within the content area of the active vertical tab to the description underneath.

Programmatically, there is also no association of the description to the body field which poses a problem for screenreader users. No one explores the entire page thoroughly, so with the description after the block of vertical tabs, the description could go unnoticed without the programmatic association most likely.

Aside those points there is also one question in regard to multilingual sites. For a site with fro example two languages, what happens if there is a translation in one language but the site is missing a translation for the other language (no translation was added/created). Will the email still be sent but just in the other existing language or will no email be sent if the translation is missing? The group considered that question a relevant detail to decide which measure to recommend - some options that came to mind would be either a warning message or should the description be expanded to inform the user about the constraints in the context of multilingual sites?

There was a clear consensus in the group to move the description into the content area of the vertical tab and display it right underneath the body field, but only when the body field is enabled and visible. The description should also be programmatically associated with the body field by the aria-describedby attribute.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

chris matthews’s picture

chris matthews commented
Status: Needs work » Needs review
Issue tags: -Needs usability review
StatusFileSize
new Welcome (new user created by administrator).png350.39 KB
new Welcome (awaiting approval).png296.63 KB
new Admin (user awaiting approval).png245.2 KB
new Welcome (no approval required).png348.56 KB
new Account activation.png387.07 KB
new Account blocked.png253.34 KB
new Account cancellation confirmation.png241.72 KB
new Account canceled.png249.66 KB
new Password recovery.png323.13 KB
smustgrave’s picture

smustgrave commented
Status: Needs review » Reviewed & tested by the community

Based on the screenshots seems straight forward enoguh.

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

apologies I've missed the updates on this issue. :( thanks for adding the changes! i've quickly tested, there is one detail to note about the current state of MR15168. All the screenshots have only the description within the vertical tabs right underneath the body field, but if you apply the MR there is also still the description "Removing all text from the body of an email will disable that email from being sent." underneath the block of vertical tabs, which feels redundant. the state outlined in the screenshots in #12 would be preferable for the MR as well imho.

talking of preferable, there is one more fundamental detail i've realized while revisiting the issue. at the moment some but not all the vertical tabs have the "Notify user when account is activated" checkbox while on every vertical tab you have the functionality if the body field is empty the particular notification will be deactivated (the functionality the description this issue introduces explains to the user). so the user is able to enable the sending of a notification on some vertical tabs by clicking the checkbox in the first step and in the next step to disable that notification right away again by leaving the body field empty. i wonder is that overcomplicating things? wouldnt it be way more straight forward to add the "Notify user when account is activated" checkbox on every vertical tab and make the body field same as the title field required? that way a notification could be activated for a certain event and if activated a required title and body make sure that also the necessary content is available to be sent? that is only personal thought, i've also left a comment in the ux channel for others to chime in as well (https://drupal.slack.com/archives/C1AFW2ZPD/p1778580336996929?thread_ts=...)

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Status: Reviewed & tested by the community » Needs work

Needs work for #14

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

Also the MR needs to be moved to be against main and not 11.x

rkoller’s picture

rkoller
he/him
Primary language German
Location Nürnberg, Germany
commented

Usability review

We discussed this issue at #3589097: Drupal Usability Meeting 2026-05-15. The link to the recording: https://www.youtube.com/watch?v=INHnpnxH7CI&t=12s . The attendees at the usability meeting were @benjifisher, @rkoller, @simohell, @the_g_bomb, and @worldlinemine.

In light of the points raised in #14 attendees re-evaluated the recommendations from the previous review.

To summarizes the problem, three of the vertical tabs have a Notify user when account is activated checkbox, while the other six vertical tabs don't have any. But the body fields on each of the nine vertical tabs share the implicit behavior; if the body field gets cleared, the notification for this vertical tab gets disabled - so the user is able to disable notifications they just enabled by ticking the checkbox. Overall the behavior and functionality across the vertical tabs on admin/config/people/accounts is inconsistent and not necessarily clear and apparent overall.

Another problem that was raised in the context for vertical tabs that can only disable notifications by clearing the body field; if you need to enable and disable certain notifications on a regular basis, you have to clear the body text and store the cleared copy somewhere else to be able to re-enable and use the previous notification text again - an awkward and error prone experience in the long run. In contrast, body fields for vertical tabs with the Notify user when... keep the body text stored when the checkbox is disabled - after ticking the Notify user when... checkbox the body text is available again.

In consequence, the group had a clear consensus about the following recommendations:

  • Add a Notify user when… checkbox to each of the nine vertical tabs.
  • Drop the implicit behavior, that clearing the body field will disable the email notification for the event the vertical tab represents is in - which makes the labels, initially introduced by this MR, obsolete.
  • Provide an upgrade path - for vertical tabs on existing sites that have no checkbox yet:
    • Body field not empty: check the Notify user when... checkbox and keep the content in the body field
    • Body field empty: uncheck the Notify user when... checkbox (*one thought in this context, while writing up the summary we haven't discussed during the meeting: it might be worth to consider to re-add the default content added on install for the respective previously cleared body field, so people have a starting point again after the enabling and disabling of notification for the respective event is now handled via the Notify user when... checkbox)

And one idea out of the scope for this issue but that might be considered for a followup. It might be a handy feature, as soon as the default text for a body field changes to provide a button to reset to the default body text underneath the body field. So the user would be able to roll back to the default at any time.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.