Do I read this correct.

Before this PR a site owner could set a limited number of super users to receive this specific email but now all super users will receive the email.

If I read it correctly and this is the case then this is a change in behaviour on an existing site that should not happen in a minor release

I made this as draft, so we can discuss.
We should have equal behaviour here and for automaded update notifications.

If we don't want to inform all super users, then we could make a users selection of all users who have the super user rights or sendEmail option = "on".
On the one hand it is better if only one super user is responsible, on the other hand it could be that nobody gets a notification, as it is now when super users change.

I am ok with J6.0, release managers can decide.

My only concern is that this proposes a change of behaviour on existing sites with no notification

What if there is another parameter using a radio for "Send to list of email addresses" or "Send to user groups" (probably different wording). Both comma separated list and group selection fields can exist and be toggled with a showon. By default it keeps the comma separated list on so it doesn't break current installations, but still allows you to set the functionality to send to a group instead.

👍 I am in favour of standardising the notification settings for update notifications so that they can be configured by groups, as is already the case for advanced scheduled tasks configurations and is new with 5.4 for automated updates.

@travisrisner Even this is I nice idea to avoid the break, I don't like adding another parameter like ‘Send to list of email addresses' as it complicates things. Sending to groups with 'Super Users' group as default is understandable and reduce Joomla administration with handling permissions in one place. And if we have a parallel opportunity to send by email addresses we have to document, test and maintain this forever.

As already written, this is a break for existing sites, they have email addresses configured, even if there won't be many of them. The effect would be that not the configured email addresses, but all superusers with receive email configured would receive the emails. I see three solutions:

1. Document the effekt, at least within the release notes
2. If configured emails are detected during the upgrade process, a warning and a hint how to solve will appear
3. Implement a seamless transition: During the upgrade:

• Check if email addresses are configured
• If so, then create a new group with those users
• And use this group for update notifications
• This has to handle some non-standard situations, as:
  • Email addresses are configured, but no user exists -> to be ignored
  • User exists, but is not in the super user group -> to be ignored
  • User exists, but is not enabled -> ???
  • Resulting list is empty -> fall back again to default Super Users group

@brianteeman Yes, number '1. Document' we have todo in each case.

And I would tend to '2. Warning' if possible. I think there are too few use cases to '3. Implement, test and maintain the seamless transition'. And the effect is only that now all members of the Super Users group get the email.

If you do this as a post-installation message then you can display it conditionally only to those sites that are effected by this change in behaviour. Better than burying this breaking change in a note in the documentation.

Thank you for your opinin. I think that this is the best solution.

And I would tend to '2. Warning' if possible. I think there are too few use cases to '3. Implement, test and maintain the seamless transition'. And the effect is only that now all members of the Super Users group get the email.

and postinstall message will be a new challenge.

There are still questions open:

1. We accept only super user groups for these messages.
   Therefor the select field can only show super user groups and must get an additional attribute for superusers only.

For existing user groups we need this: (also see comments above)
The owners of the comma separated addresses have to be added into a newly generated usergroup with permission "core.admin".
The original input field then can be removed
a ) This new usergroup needs a name which does not exist in the system. I could use "super user update notification" if this does not exist yet or use a time-date suffix for the super user group.
b) Is it possible to do this during an update, using a update script? @richard67.

As Suggested, a postinstall message additionally to the information in release notes will be added.

I close this one and make a new PR with the better code from the autoupdate PR. Thanks for the hints @HLeithner!

Probably better for 6.0 or 6.1?

@chmst since it's too late for 6.0, please target 6.1