Add support for userrights, usergroups or autopromotion dependent on having a continous or periodic confirmed email address
OpenPublic

Description

Author: rd232

Description:
We currently have [[Manual:$wgEmailConfirmToEdit]] as an option to require users to supply an email address in order to edit. Per https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia:Village_pump_%28proposals%29/Account_security, 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

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz30018.
bzimport created this task.Via LegacyJul 22 2011, 8:58 PM
MarkAHershberger added a comment.Via ConduitJul 25 2011, 10:54 PM

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?

bzimport added a comment.Via ConduitJul 26 2011, 10:41 AM

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

bzimport added a comment.Via ConduitJul 29 2011, 2:24 AM

happy.melon.wiki 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.

bzimport added a comment.Via ConduitJul 29 2011, 9:33 AM

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

duplicatebug added a comment.Via ConduitNov 11 2012, 12:01 PM

For autopromote the condition APCOND_EMAILCONFIRMED is available.

bzimport added a comment.Via ConduitApr 29 2013, 3:17 PM

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 (http://www.mediawiki.org/wiki/Manual:$wgAutopromote). So that's something. But that's special to that pseudo-group and can't easily be extended to others.

Qgil added a comment.Via ConduitApr 30 2014, 6:51 AM

A year later...

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

duplicatebug removed a subscriber: duplicatebug.Via WebDec 13 2014, 11:36 AM

Add Comment