Allow expiration warning emails to be customized/disabled

It is possible to set a checkbox in the "admin/config/people/user-expire" form and set a Drupal variable to determine if a Email have to be sent to inactive users.

See this patch if it is good for your use case.

I applied the patch in #2 . give me error. Please check the screen. I think patch needs a reroll.

I reroll and tested the patch and it works.

Patch working fine for me.
Regenerated, if it can help.

Can confirm patch in #7 is working well. Would be good to extend this to allow customization of the email template as well.

Thanks for the work writing and testing this.

There was a test failure the last time this was tested, so it needs work to make sure that the test is fixed or the code is fixed (or both).

The failure was "Expected text found in subject of email message: "Account expired"."

I'm hijacking this issue for the 8.x-1.x version, if it is accepted, we can do a re-backport :-)

The pull request adds UI elements to the config form to enable/disable the notification email and allows admins to customise the notification email. I've replaced the hardcoded limited set of tokens with that standard set of [site:] and [user:] mail tokens.

Uploading a 7.x patch too, so I can use it in composer.

This has a conflict now so needs a reroll. Marking needs work for that.

Thanks cafuego and others for the work on this so far.

Hateful gitlab won't let me push to the feature branch for reasons I cannot fathom.

All the tests are green, so I guess now the only question is "does it still do what it is supposed to do" ;-)

Uploading latest MR diff as static patch file usable for composer.

We've tested the MR/patch with good results and are hoping this change will be committed soon as we'd like to use this module on several sites.

Most of the testing I've done with this patch was with the functionality for disabling email notifications. Taking a closer look at the functionality for customizing the notification email subject and message I see a potential config schema improvement that we may want to address before merging this.

I think we should replace the new mail.subject and mail.body config settings with a single setting of the mail config schema type consistent with how the core user module mail configuration settings work.

I also wonder if we need to include a database update function to apply the default mail config setting(s) to existing sites.

Created a new MR targeting 2.x branch that includes rebased changes from original 8.x-1.x MR + the config schema changes and DB update described in #19.

I think the machine names for the settings should be more specific so they don’t exclude additional email/notification options, we can address the confusing labels in the config interface in follow-up issue #3463221: Review and improve form field labels and description

Looks good to me!

Made some more improvements to the new settings in the settings form and the overall implementation of when the warnings are sent. This ready for final review now IMHO.

Created new branch from existing MR (duplicate MR) to trigger tugboat.

Merged.