Last modified: 2014-04-30 06:51:05 UTC
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.
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?
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".
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.
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.
(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.
A year later... How relevant is this problem today? How good is the solution proposed? How complex the potential solution?
