Page MenuHomePhabricator

Require some user groups to have a periodically confirmed valid email address
Open, LowestPublicFeature


Author: rd232

We currently have [[Manual:$wgEmailConfirmToEdit]] as an option to require users to supply an email address in order to edit. Per, it would be useful to be able to control this per user group or per user right. For example, if the sysop user group is configured to require a verified email address, then sysop user rights would not be available to a member of the group if that member doesn't have a verified email address.

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:48 PM
bzimport set Reference to bz30018.
bzimport added a subscriber: Unknown Object (MLST).

forgive my ignorance, but couldn't you just avoid making people a sysop if they didn't have a verified email? Or is the intent here to remove fumble-fingered mistakes?

rd232 wrote:

There's relatively little benefit to making people provide a verified email address at one point time. On long-lasting wikis, verification might have been 5-10 years ago. The aim of this bug is to make user rights dependent on a verified email address *on an ongoing basis*. So for example if the user removes the email address, or replaces it with another but doesn't verify it, the user rights associated with their user group are automatically suspended, until a verified email address is provided, when they're automatically re-enabled. This would be more useful if there are situations where the "verified" status of an existing email address can be automatically revoked (eg if emails to the user bounce); I'm not sure if that's the case but if it isn't that's a separate issue.

I should note that this bug is partly because of a desire to use email notifications to enhance security, which is obviously dependent on a current email address. (A "verified" email address may not be current, but it's the best proxy available at the moment.) See also Bug 26227 - "Notify user by email when password changed"; Bug 29856 - "Email notification when verified email address is changed or removed"; and Bug 29857 - "Welcome back email notification after renewed account activity". wrote:

I believe we already have an 'emailconfirmed' implicit usergroup. The simplest way of implementing this would be to implement the opposite, an 'emailunconfirmed' group. Then $wgRevokePermissions['emailunconfirmed'][<perm>] revokes the right when the user is unverified. This also seems to have the best aesthetic of fine-grained control over which permissions are affected by the feature.

rd232 wrote:

That sounds good, but it should be "noemailconfirmed", since we're not just interested in cases of "email address exists, but isn't confirmed" but also "no email address given".

For autopromote the condition APCOND_EMAILCONFIRMED is available.

rd232 wrote:

(In reply to comment #5)

For autopromote the condition APCOND_EMAILCONFIRMED is available.

Yes, I think that does the requested feature for autoconfirmed users, because of the way autoconfirmed status is checked every time user rights are verified ($wgAutopromote). So that's something. But that's special to that pseudo-group and can't easily be extended to others.

A year later...

How relevant is this problem today? How good is the solution proposed? How complex the potential solution?

Krinkle renamed this task from Add support for userrights, usergroups or autopromotion dependent on having a continous or periodic confirmed email address to Require some user groups to have a periodically confirmed valid email address.Apr 12 2020, 10:58 PM
Krinkle moved this task from Backlog to User rights on the MediaWiki-User-management board.
Krinkle unsubscribed.

I think the implementation of this should be similar to T150562: Be able to force OATHAuth for certain user groups. If having a confirmed email is a requirement for group membership, you lose that membership when your email becomes unconfirmed (manual removal, BounceHandler, etc.) and you automatically regain it when your email is confirmed again.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM