Page MenuHomePhabricator

Notify users when their user group membership is about to expire, or has expired
Open, Stalled, LowPublic8 Story Points

Description

Currently, as part of the manual permission expiry process, a notification template is posted to a user's talk page "a few days" before their rights are removed.

When this functionality is available in core MediaWiki, it would be nice to provide users with a notification that their rights are soon to expire. Possibly a week before expiry, or a day before if the rights were assigned for less than two weeks. It would also be nice to send a notification when the rights finally expire.

Basic information

  - Purpose of the notification:  Provide users with notice that their membership of a user group/groups are about to expire/have expired, giving them the opportunity to start a community discussion to have their rights renewed, or just acting as a courtesy notification.
  - Notification name:  user-rights or user-rights-expiry (not sure if it needs to be separate from existing user-rights notification)
  - What triggers notification?: The notifications would have to be timed, rather than being created reactively. See my comment below.
  - "Notice" or "Alert"?:  Alert (?)
  - Notification type (standard, bundled, expandable bundle):  Standard

Wording

For a single message

  • Header: Your user rights [are about to expire/have expired]
  • Body: Your sysop and bureaucrat permissions [will expire on DATE/have expired].

For Bundled Messages

  • Main, bundling message: Don't think we need bundling.
  • Subsidiary, bundled message:

Links

  - Primary link target: Not sure. The existing user-rights notification points to Special:ListGroupRights, which is a pretty silly target. Personally I don't think user rights notifications need any target at all.
  - Primary link label (for email display only):

  - #1 secondary link target: Log entry where the expiring user groups were assigned (see UserRightsPresentationModel::getLogLink())
  - #1 secondary link label: User rights log

  - #2 secondary link target:
  - #2 secondary link label:

Icon

  - Icon name:  user-rights

Related Objects

Event Timeline

TTO created this task.Dec 21 2016, 5:09 AM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptDec 21 2016, 5:09 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyH moved this task from Untriaged to Epic backlog on the Community-Tech board.Dec 22 2016, 5:41 PM
TTO added a comment.Dec 25 2016, 12:22 PM

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.

jmatazzoni added a subscriber: jmatazzoni.

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?

TTO renamed this task from Notify users when their user group membership is about to expire to Notify users when their user group membership is about to expire, or has expired.Jan 4 2017, 3:37 AM
TTO updated the task description. (Show Details)

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

I had a go.

TTO added a subscriber: Krenair.Jan 5 2017, 11:01 AM

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.

Legoktm added a subscriber: Legoktm.Mar 8 2017, 1:54 AM

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.

TTO added a comment.Mar 8 2017, 10:56 AM

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.)

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?

@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.

kaldari added a comment.EditedApr 8 2017, 1:31 AM

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).

TTO added a comment.EditedApr 8 2017, 3:35 AM

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

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 T159416, "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?

TTO added a comment.Apr 13 2017, 6:39 AM

@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.

TTO added a comment.Apr 13 2017, 7:07 AM

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.

MaxSem added a subscriber: MaxSem.Apr 21 2017, 8:07 PM

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.

MaxSem added a subscriber: Yurik.Apr 24 2017, 7:55 PM

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.

MaxSem claimed this task.Apr 25 2017, 2:50 AM
TTO added a comment.EditedApr 25 2017, 3:02 AM

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

kaldari moved this task from Ready to In Development on the Community-Tech-Sprint board.
kaldari set the point value for this task to 8.Jun 5 2017, 10:32 PM
kaldari changed the task status from Open to Stalled.Jul 20 2017, 8:09 PM

Currently stalled, pending T168107/T156808.

kaldari moved this task from Epic backlog to Bug backlog on the Community-Tech board.

Change 350500 abandoned by MaxSem:
Add user right expiry notifications

Reason:
Not working on this.

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

Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 28 2018, 10:28 PM

@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.