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


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

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 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 ($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