This actually looks to be non-trivial, because Echo is currently a purely reactive mechanism - it listens to various hooks, and when one is triggered with the necessary conditions being met, it creates a notification for the relevant user(s). There's no mechanism in Echo to send notifications at arbitrary times (such as two weeks before a user right expires). Even sending a notification at the moment when the rights expire isn't possible, since the expiry is a passive thing (a certain DB condition ug_expiry < wfTimestampNow() no longer evaluating to true) that doesn't actually "happen" and can't be hooked.

Some thought would need to be given as to how expiry notifications could be issued in this context. (A hypothetical implementation: When expiring user rights are applied, Echo could (via a hook) record some sort of DB entry saying "issue a notification to user X at time Y"; then an hourly or daily cronjob comes by and issues those notifications when time Y arrives.)

It would be useful to come up with other examples of non-reactive notifications that we might want, as they might help to guide our thinking in terms of implementation. I found T2582: Remind me of this article in X days and T88781: Create a Timer based reminder for workflows as a start...

I see this as being a fairly crucial piece of the puzzle that is T12493, so it would be interesting to think about this some more. Since this links to both the 2015 and 2016 Community Wishlists, this might be a great one for CommTech to take on.

I've pasted the New Notification Request Form into the Description. This is a good first step for any new notification. @TTO, can you take a stab at filling this in?

In T153817#2913623, @jmatazzoni wrote:

@TTO, can you take a stab at filling this in?

I had a go.

In T154553#2916736, @Krenair wrote:

If we have an asynchronous process to delete expired rows [in the user_groups table], if it runs often enough, it could also take care of notifications?

That's an interesting idea. In the current incarnation of my patch, every time a new user group is assigned, a DeferredUpdate is queued to purge expired user_groups rows. (This is essentially the same as what the Block class does.) This is fine for purging user rights rows - in the long term, the rate at which group memberships expire won't exceed the rate at which groups are assigned. But it's unlikely that this could be useful for sending notifications. Stewards will be assigning temporary adminships on very small wikis, where Special:UserRights might see activity only once or twice a year.

It might be possible to hook into some other event, for example, when the user in question edits a page or something. (Or even on every page view... We must already be loading the user_groups row somewhere to know which links and tabs to show, so we could check it and launch a job to send the notification... Don't tell the Performance team I suggested that though!) But in the long term, I think some kind of schedule-based system for notifications is going to be needed, particularly if the tasks I identified in my last comment are ever going to be solved. That type of scheduled reminder notification will have to be issued at the set time, even if the user isn't visiting the wiki, so a reactive solution won't cut it.

The job queue already supports delayed jobs, we could theoretically queue a delayed job to run in a year or so to trigger the expiry notification.

In T153817#3082933, @Legoktm wrote:

The job queue already supports delayed jobs, we could theoretically queue a delayed job to run in a year or so to trigger the expiry notification.

Are we sure that jobs will stay in the queue for 1 or 2 years, or longer? It doesn't really seem like that is what the job queue is designed for.

There's already an Echo event for rights changes (type: user-rights). Personally, I would recommend against having an Echo notification for upcoming rights changes. That would be spammy, IMO, as we would be generating 2 notifications for each change. (And as you mentioned, Echo is not architected to handle such notifications anyway.)

In T153817#3165377, @kaldari wrote:

There's already an Echo event for rights changes (type: user-rights).

Not only does that notification exist, the user right expiry change broke it (or at least made it nonsensical) because it wasn't updated: T159301: User group membership notification about changed expiration date should be more specific

@Catrope: Does the existing user-rights notification notify users only when the expiration is set (at the addition of the right) or also when the right actually expires?

In T153817#3165464, @kaldari wrote:

@Catrope: Does the existing user-rights notification notify users only when the expiration is set (at the addition of the right) or also when the right actually expires?

AFAIK it notifies when the right is added, and also when the expiration is updated. The latter is what that bug is about, as the message doesn't comprehensibly inform you that that's what's happened.

Got it. In that case, it sounds like we should trigger the user-rights notification with the remove parameter at the point at which the right actually expires and is automatically removed (which should be doable).

Should be doable, but maybe not as trivial as you might think:

In T153817#2901440, @TTO wrote:

Even sending a notification at the moment when the rights expire isn't possible, since the expiry is a passive thing (a certain DB condition ug_expiry < wfTimestampNow() no longer evaluating to true) that doesn't actually "happen" and can't be hooked.

It would be simple enough though to do this using a cronjob in Echo. I proposed a solution at T156808: Back-end infrastructure for timed notifications in Echo, which ought to be relatively simple to implement.

As I commented at T186316, "This is a nice-to-have sort of thing that I am definitely going to keep pushing for, but it doesn't seem like a critical ingredient to me", so I don't think we ought to consider it a blocker. Particularly because I've made assurances that expiring user groups will be enabled before MW 1.29 goes out so we can get rid of the feature flag. Otherwise we could be sitting here for a very long time.

Removed this as a blocker per my most recent comment.

@TTO: What about sending notifications from UserGroupMembership::purgeExpired()? They might be slightly late, but better late than never, right?

In T153817#3177434, @kaldari wrote:

@TTO: What about sending notifications from UserGroupMembership::purgeExpired()? They might be slightly late, but better late than never, right?

purgeExpired() is only called when a user group is added or removed. One of the main audiences for the user group expiry feature is small wikis, where the user rights interface might be used as infrequently as once or twice a year, so you could be waiting a very long time for that notification...

Hmm, perhaps purgeExpired() could be called by something that happens more frequently, or even by an automated daily maintenance script (similar to purgeUnusedProjects.php). The downside of relying on an automated maintenance script is that it wouldn't be very convenient for 3rd party wikis. The other option, creating a delayed Echo notification, is also problematic though, as you would need to track down and update or replace the delayed notifications every time you changed the expiration.

In T153817#3177487, @kaldari wrote:

Hmm, perhaps purgeExpired() could be called by something that happens more frequently, or even by an automated daily maintenance script (similar to purgeUnusedProjects.php).

Possibly. But this doesn't solve the issue of raising a notification when rights are about to expire, which would be useful to have in the context of the temporary user right process on Meta. In fact that is possibly more important than the notification when the rights actually expire, because it gives users time to start a community discussion to renew their rights. You wouldn't want to hack that into purgeExpired, would you?

The other option, creating a delayed Echo notification, is also problematic though, as you would need to track down and update or replace the delayed notifications every time you changed the expiration.

I don't think it would be insurmountably difficult. You could simply look for a delayed notification with a matching notification type, user, and group.

I think a maintenance script should be the way to go. It would send pre-expiry notifications immediately and enqueue timed jobs for rights expiring within next 24 hours. No complex future notification search and deletion is needed as long as jobs verify that user right parameters are still the same.

Next question: what to do if the right was assigned from Meta? It would not be reflected in local user rights log thus we will be leading people to empty or misleading logs.

In T153817#3208611, @MaxSem wrote:

Next question: what to do if the right was assigned from Meta? It would not be reflected in local user rights log thus we will be leading people to empty or misleading logs.

In fact, from testing on the Beta cluster, it seems that no Echo notifications are issued at all for cross-wiki rights changes... This is T53540: Support cross-wiki rights change notification in Echo

Change 350500 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/Echo@master] WIP: Add user right expiry notifications

https://gerrit.wikimedia.org/r/350500

Change 350961 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/core@master] Automatically purge expired user groups

https://gerrit.wikimedia.org/r/350961

Change 350961 abandoned by MaxSem:
Automatically purge expired user groups

Reason:
Discussed with Aaron in person, going in a different direction.

https://gerrit.wikimedia.org/r/350961

Change 350500 abandoned by MaxSem:
Add user right expiry notifications

Reason:
Not working on this.

https://gerrit.wikimedia.org/r/350500

@TTO, a small point: I notice you have not defined a defined a Primary Link Target. But you do have a Secondary Link Target. To clarify, the Primary Link is where the user goes if she just clicks on the notification body. The secondary links are the little, explicit links/labels underneath the message body.

If I might make a suggestion: perhaps it would make sense to just make the current Secondary Link ("Log entry where the expiring user groups were assigned...") the Primary, and not have a Secondary.

If the notifications can be provided after groups have expired:
Add a hook to UserGroupExpiryJob called before the expired rights are removed
Extension (echo) checks what groups are expired, and adds notifications
Core removes the expired groups

For what's worth, T370842 does this now (have been busy applying for authorisation on various projects, and already running on a few projects). I'm not sure how important this task itself is as a result.