as a followup to adding settings to notify users on account status changes, and to potentially pave the way for email users upon change of role, i've been thinking more about this UI. what if an admin both approves a user and puts them in some new roles? they shouldn't get 2 different emails. instead of different settings for each possible change to the status, we only need 4 template settings:

  1. user created by admin
  2. user registered herself, no approval required
  3. user registered herself, pending approval
  4. user account changed

there would be additional admin settings that defined template paragraphs that could be conditionally loaded into any of (therefore shared among) these overall message templates. for example, there might be the following paragraphs defined:

  • !p_active
  • !p_deleted
  • !p_blocked
  • !p_roles_added
  • !p_roles_removed
  • !p_temp_login

each token would have a value if the changed happened, or would be removed if the status didn't match or there was no change of roles, etc. if a new 1-time login link was made, !p_temp_login would be a paragraph that describes how to use the login link. !p_temp_login could be shared among the password reset, account approved by admin, and new account registration messages, for example...

to define each of these paragraphs, you'd have access to specific tokens. in addition to the existing tokens, there might be others like:

!roles_current
comma separated list of the user's current roles
!roles_added
list of the roles added to the account
!roles_removed
roles removed from the account
!status_current
"active", "blocked", (it'd be nice if we had "pending" in here as a distinct status, but that's for another patch).

then, the default value of the "user account changed" message body would be something like:

!username,

!p_active
!p_temp_login
!p_roles_added
!p_roles_removed
!p_blocked

-- !site team

that way, if an admin approves an account and adds some roles, the user gets 1 email that might look something like:

dww,

Your account at baterialucha.org is now active.

You may now log in by clicking on this link or copying and pasting it in your browser:

!login_url

This is a one-time login, so it can be used only once.  After logging in, you will be redirected to !edit_uri so you can change your password.

This site has different kinds of users based on the roles they play, with varying levels of permission and access.  You have been added to the following user roles: band member, organizer, administrator.

the template for accounts created by the admin would be something like:

<code>
!username,

An administrator has created an account for you at !site.

!p_temp_login
!p_roles_added

-- !site team

if the site doesn't care about separately worded paragraphs for each possible status change, they could just use this for the start of their "user account changed" message body:

!username,

Your account at !site is now !current_status.
...

open questions:

  1. maybe we want to keep the password reset as its own message template, so you can customize the introduction before the !p_temp_login, or perhaps we just need another conditional account change token like !p_password_reset_requested.
  2. are we going to get screwed with tokens inside of tokens? seems like we're going to have pass the message templates through the token translation recursively, until no more tokens are matched and replaced. or, perhaps we want different symbols at the front of the different kinds of tokens, and they get replaced in a fixed order? that seems more ugly and inflexible to me.
  3. do people think this is too confusing and complicated a UI for end-user admins to grasp and configured properly?
  4. should we provide a UI for site admins to define their own new paragraph tokens if they wanted to insert
    shared text into all of the messages? (a shared site-specific signature, for example)

Comments

michelle’s picture

I really like the idea over all. For your questions:

1) I think differentiating between a password request and a new account one time log in is a good idea.

2) I don't know enough about the internals to answer this one.

3) I don't think it's confusing if you have a list of tokens available and what they mean. I don't think the whole replacement idea is complex and should be fine.

4) I think this is probably over kill... There's not going to be _that_ many different messages so they can copy and paste if they want something in all of them.

Michelle

dpearcefl’s picture

Is there any interest in pursuing this issue? Meaning is any one interested to roll a patch?

michelle’s picture

Version: 6.x-dev » 8.x-dev

I don't know if this is still useful but we're well past getting FRs into D6. :)

Michelle

dpearcefl’s picture

Without a patch, the issue perishes...

dww’s picture

Assigned: dww » Unassigned

Yeah, sorry, I have no time to push this forward. If anyone else wants to run with it, go for it. ;)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)

Wonder after so many years if this is still needed?

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Another two years and there is no discussion or support for this idea.

The proposal doesn't met the Criteria for evaluating proposed changes. In this case, there is not demonstrated demand and support for the change.

If there is interest in this re-open the issue and add a comment. Or open a new issue and reference this one.