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.
|Open||None||T190350 Epic: ⚡️ Partial blocks|
|Resolved||• TBolliger||T104099 Allow users to be blocked from using Special:EmailUser only|
- Mentioned In
- T242541: Allow partial blocks against specified actions
T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace
T190350: Epic: ⚡️ Partial blocks
T193449: Draft a proposal for granular blocks table schema(s), submit for DBA review
- Mentioned Here
- T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace
T169934: Reconsider how users can be contacted (email, talk page, notifications) on wikis where they have never edited but have logged-in.
T12493: Setting a temporary usergroup (allow expiry of user rights via Special:UserRights form)
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 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?
@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"
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.
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?