Page MenuHomePhabricator

Allow users to be blocked from using Special:EmailUser only
Closed, ResolvedPublic

Description

The abusing of the email function is possible, so I thing it would be helpful, if sysops could split the blocking of mail, and the blocking of writing. After this is solved, there could also the possibility to give the users only the rights "blockemail" but not the "block" right, so the could block email only. At the moment the right "blockemail" without the right block allows nothing.

Event Timeline

Luke081515 raised the priority of this task from to Needs Triage.
Luke081515 updated the task description. (Show Details)
Luke081515 added a subscriber: Luke081515.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 28 2015, 12:41 AM
Luke081515 renamed this task from Allow blocking wikimail only to Allow blocking email only.Jun 28 2015, 12:44 AM
Luke081515 set Security to None.
Luke081515 updated the task description. (Show Details)

I fail to see the need of this proposed feature. If you can't trust a user with e-mail function he should probably blocked with the default parameters.

You can do a hack:

$wgRevokePermissions['emailblocked']['sendemail'] = true;

and set $wgAddGroups and $wgRemoveGroups appropriately.

Then you can add such users to "emailblocked" group. Note this can not block users from sending emails temporary unless you manually unblock them (which is T12493: Setting a temporary usergroup (allow expiry of user rights via Special:UserRights form)).

Luke081515 added a comment.EditedJun 28 2015, 12:00 PM

Steinsplitter added a subscriber: Steinsplitter.
I fail to see the need of this proposed feature. If you can't trust a user with e-mail function he should probably blocked with the default parameters.

There are useful cases, like at wikipedia, when an arcom disalow this a user.

Aklapper triaged this task as Lowest priority.Jun 29 2015, 9:56 AM
MGChecker added a subscriber: MGChecker.

I also think this feature can be really useful at wikipedia.

kaldari reopened this task as Open.Jul 6 2017, 9:13 PM
kaldari added a subscriber: kaldari.

Unduplicating due to scope change of other bug.

kaldari raised the priority of this task from Lowest to Normal.Jul 6 2017, 9:14 PM
kaldari added a project: Anti-Harassment.
kaldari renamed this task from Allow blocking email only to Add ability to block users from emailing other users (without performing a full block).Jul 6 2017, 9:16 PM
kaldari moved this task from Untriaged to Backlog on the Anti-Harassment board.

Maybe useful but easy to get around by going to another wiki (at least in the WMF farm) and using special:emailuser there where both the sender and the recipient accounts do exist.

Yes, so we probably need a global feature (and the hack above will not be useful as we don't have a global revoke permission feature).

Maybe useful but easy to get around by going to another wiki (at least in the WMF farm) and using special:emailuser there where both the sender and the recipient accounts do exist.

That's a hole that should probably be mended regardless of this ticket. I've created T169934 to track this topic.

TBolliger moved this task from Backlog to Untriaged on the Anti-Harassment board.Jul 6 2017, 10:22 PM
TBolliger renamed this task from Add ability to block users from emailing other users (without performing a full block) to Allow blocking of Special:EmailUser (without performing a full block).Jan 12 2018, 11:15 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.Mar 9 2018, 1:52 PM

This will be possible after T2674 is completed.

This will be possible after T2674 is completed.

@alexhollender should probably be made aware that it will be possible to do neither a site block or a granular block, but you could just apply some other sanction (like email blocking). How would this work in the design?

Perhaps a third radio button for "only actions" — users will also be able to only be blocked from uploading files (and someday maybe moving pages.)

Perhaps a third radio button for "only actions" — users will also be able to only be blocked from uploading files (and someday maybe moving pages.)

or alternatively, just use checkboxes for everything (and some are mutually exclusive, so will be disabled). :)

Perhaps a third radio button for "only actions" — users will also be able to only be blocked from uploading files (and someday maybe moving pages.)

or alternatively, just use checkboxes for everything (and some are mutually exclusive, so will be disabled). :)

I wonder if this flow could be considered a type of Granular Block, with no pages/categories/namespaces declared...just kinda sketching this out:

  • We could update the text to be:
    • Site-wide block: User or IP address will be blocked from editing all pages on the site, and any actions selected below
    • Granular block: User or IP address will be blocked only from pages, categories, namespaces, and actions specified below
  • User would select "Granular block"
  • User would leave all 3 fields (Pages, Categories, Namespaces) empty
  • User would select the actions to block

I think the drawback of this approach is that it isn't particularly intuitive, however if this workflow isn't particularly common that might be fine?

Introducing a third radio button seems slightly heavy-handed (again, depending on how common this is).

Using checkboxes seems like it could be a little confusing because you can't select Site-wide and Granular at the same time? Or am I missing something?

I agree a third radio button could be unnecessary. I like changing the description to include 'actions'.

Maybe we can consider moving the "Prevent user from" and "additional options" above the duration and reason?

@TBolliger

Maybe we can consider moving the "Prevent user from" and "additional options" above the duration and reason?

+1. Check out this wireframe and lmk what you think

Looking good! It's kind of a shame this added more vertical height, but it looks good.

+1,000,000 to 'partial blocks' over 'granular blocks'

@alexhollender I like it a lot!

Mostly I like it because this task will be passively complete when T2674 is done. :)

I also like "Partial Blocks" over "Granular Blocks"

Using checkboxes seems like it could be a little confusing because you can't select Site-wide and Granular at the same time? Or am I missing something?

It would just be a "Site-wide" checkbox, there would be no Granular checkbox. So if Site-wide was checked, the granular fields would be disabled and unchecking the Site-wide box would make the fields enabled.

Though, I think the radio buttons are fine and give more room for an explanation, but using checkboxes might better imply that it's all optional.

@dbarratt gotcha. Let me know if this is what you were thinking of. I like the simplicity of it. We said that site-wide blocks would be the default option, so that checkbox would be checked by default. Maybe we'd want to find a word other than "Pages" to describe the combination of pages, categories, and namespaces. Curious what you and @TBolliger think.

@dbarratt gotcha. Let me know if this is what you were thinking of. I like the simplicity of it. We said that site-wide blocks would be the default option, so that checkbox would be checked by default. Maybe we'd want to find a word other than "Pages" to describe the combination of pages, categories, and namespaces. Curious what you and @TBolliger think.

oooo! I like it! I'm not sure which version I like better. it seems a lot simpler this way and... idk... more inviting(?) to create a partial block.

You could use something like "Items" but that seems generic....

so perhaps leave it as pages and change "Categories" to something like "Pages in these Categories" and change "Namespaces" to "Pages in these Namespaces", since you really aren't blocking the Categories or the Namespaces themselves, just the pages within the categories and namespaces.

dmaza added a subscriber: dmaza.Jun 4 2018, 5:18 PM

I think the labels on the last one are better but I find the radio buttons less confusing. Maybe instead of using "Side-wide block" we could say "Block user from all pages" and so on(?)

Let's keep in mind that we expect the vast majority of blocks to still be full-site blocks, so both the default behavior and the UI should reinforce this. We're also getting some pretty solid support on wiki (English Wikipedia and Meta Wiki) for the radio button design, so we shouldn't stray too far unless we have a strongly compelling reason.

@dbarratt @dmaza @TBolliger — based on our discussion here, and the clear feedback from the community, it seems like we've got three options for presenting the full/partial block options in the form. After thinking about how the options compare, I think the main thing I'm wondering is: do we want to encourage users to make partial blocks over making full site blocks? I think the answer to that question might help us pick.

Option 1) emphasizes "full block" a bit more by making it feel like it's own default option
Option 1.2) starts to emphasize "partial block", but still gives a lot of prominence to "full block"
Option 4) deemphasizes "full block" by making it seem more like an override rather than a default option

@TBolliger I found the last round of community feedback/voting helpful. I'm wondering if you think it'd be appropriate to ping them again with this updated option set, or if we should make the decision amongst ourselves?

I'm writing a summary of feedback to date and will post it tomorrow. I'll include this image and ask if folks have any preferences.

I prefer Option 4 just because it looks so slick. Great job @alexhollender!

TBolliger renamed this task from Allow blocking of Special:EmailUser (without performing a full block) to Allow users to be blocked from using Special:EmailUser only.Jun 11 2018, 9:25 PM
TBolliger closed this task as Resolved.Jan 30 2019, 9:43 PM
TBolliger claimed this task.

This is done and live on wikis with Partial Blocks enabled.

To test, use test.wikipedia.org