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

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.

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

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

In T104099#3413564, @MarcoAurelio wrote:

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.

This will be possible after T2674 is completed.

In T104099#4247374, @TBolliger wrote:

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

In T104099#4247412, @TBolliger wrote:

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). :)

In T104099#4247434, @dbarratt wrote:

In T104099#4247412, @TBolliger wrote:

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"

In T104099#4249662, @alexhollender wrote:

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.

In T104099#4254208, @alexhollender wrote:

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

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!