Page MenuHomePhabricator

Prohibit empty blocks
Closed, ResolvedPublic3 Estimated Story Points

Description

If an admin (or whomever holds block permissions) sets a partial block but includes no actions to block, the block should not be set.

Acceptance criteria

  • The 'Block' (or variant) button should be marked as disabled if a block is configured as non-editing but holds no non-editing actions (email, account creation, and in the future upload, page create, etc.)
  • The API should submit an appropriate error message if this type of block is set via API.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
IKhitron removed a subscriber: IKhitron.Nov 3 2018, 2:59 PM

Also, if this SHOULD work - the UI appears to have no way to issue someone a general 'non editing actions' block while they are also blocked from editing at least one specific page.

I believe this should be resolved with T6995 correct @TBolliger?

dmaza added a subscriber: dmaza.Nov 5 2018, 2:50 PM

I believe this should be resolved with T6995 correct @TBolliger?

Yes, this is currently not an option when creating a non-editing block

@dmaza T6995 looks to be about ONLY upload blocks?

dbarratt added a comment.EditedNov 5 2018, 4:52 PM

The blocked user can still perform the non-editing action of upload

This is a feature, not a bug.

When T6995 is complete the admin will be able to specify if a user should or should not be blocked from uploading.

@TBolliger, correct me if I'm wrong. :)

@Xaosflux

Can you explain what this means?

The system reports the user is blocked from "from non-editing actions"

Where does it report that? What does it look like? Can you post a screenshot if possible?

Hi! There are a few things I want to comment on.

#1 — The concept of "non-editing actions"

We want to make it possible for admins to configure a block so the user can edit all pages but not perform certain actions, such as uploading files, creating new pages, or emailing other users. Currently the only pieces of this functionality that work are sending email and creating accounts (both of which are minimally used by logged-in users, but were 'free' because they were already part of Special:Block.)

Our team is working on bugfixes to page blocks and then adding in namespace blocks. We'll get to the upload and page creation blocks after that.

#2 — The UI of Special:Block

The final designs will better explain this. We released this first iteration of partial blocks to test wiki with an extremely minimal change to the UI. Our wireframes for the final design can be found here: M255 and we will take T202773 into a near-future sprint for development.

#3 — The log entry text of "non-editing actions"

The current phrasing of the log entry is proving to be confusing. We want to add the word specified to make it more clear: T208806


I'll leave this task open for a few days so we can discuss, but otherwise I think this can be closed as invalid.

@TBolliger fixing that log verbiage is OK, but there is a different problem that should be solved:

A partial block of specified non-editing actions should fail if no non-editing actions are provided.

@TBolliger fixing that log verbiage is OK, but there is a different problem that should be solved:

A partial block of specified non-editing actions should fail if no non-editing actions are provided.

You're 100% correct. I would say that the 'block' button should be inactive (therefore signaling incomplete input) and the API should send an appropriate error message.

TBolliger renamed this task from partial block "non-editing actions" does not prevent upload action to A partial block of specified non-editing actions should fail if no non-editing actions are provided..Nov 5 2018, 11:14 PM
TBolliger updated the task description. (Show Details)

You're 100% correct. I would say that the 'block' button should be inactive (therefore signaling incomplete input) and the API should send an appropriate error message.

I see. So this means that you haven't actually blocked the user from anything? i.e. you haven't blocked them from account creation or from sending email, etc.?

yes, if the admin (or whomever is setting the block) configures it so the block will have no effect (short of being logged) then it should be prevent from being submitted and saved as a block.

yes, if the admin (or whomever is setting the block) configures it so the block will have no effect (short of being logged) then it should be prevent from being submitted and saved as a block.

oh ok. I would describe that as being empty unless you have a better word for it. :)

TBolliger renamed this task from A partial block of specified non-editing actions should fail if no non-editing actions are provided. to Prohibit empty blocks.Nov 6 2018, 12:51 AM

The new title and description seem better now, ultimately that was the problem, and making "something" blocked be a required element (just like other required elements such as the blocked account) is the fix.

TBolliger triaged this task as Low priority.Nov 16 2018, 3:37 PM
TBolliger removed a project: Anti-Harassment.

Deprioritizing new feature development on Partial Blocks in 2019 by the WMF's Anti-Harassment team but leaving open on the Blocking Tools backlog. After we measure the effectiveness of page and namespace Partial Blocks we will reassess additional time investment.

Niharika raised the priority of this task from Low to Medium.Jul 30 2019, 5:17 PM
Niharika added a project: Anti-Harassment.
Niharika added a subscriber: Niharika.

I think it's worthwhile to prioritize this now that we are rolling partial blocks to bigger wikis. Let's discuss this in our next team meeting.

Niharika set the point value for this task to 3.Jul 31 2019, 4:15 PM

Deprioritizing this task in favor of our upcoming work on CheckUser.

jrbs added a subscriber: jrbs.Jan 17 2020, 5:19 PM

Perhaps this might be alleviated with a confirmation window of some kind ("Are you sure you wish to submit an empty block?") though I don't really know what the benefits of performing an empty block would be. Just some thoughts when this is re-prioritised.

@jrbs Wouldn't this technically be handy for final warnings? Though it probably wouldn't be that beneficial for users, but it could show the seriousness of a warning.

jrbs added a comment.Jan 19 2020, 10:59 PM

@jrbs Wouldn't this technically be handy for final warnings? Though it probably wouldn't be that beneficial for users, but it could show the seriousness of a warning.

Personally this is the equivalent of shooting a gun into the sky to prove that it's loaded. But if the person never hears the shot and the person firing doesn't know they've pulled the trigger....

Niharika added a comment.EditedApr 30 2020, 7:27 PM

@DannyS712 Are you interested in picking this one up by any chance? It's pretty clear that this is a bug we should fix. Doesn't seem to involve much user-facing changes.

@DannyS712 Are you interested in picking this one up by any chance? It's pretty clear that this is a bug we should fix. Doesn't seem to involve much user-facing changes.

Will do. If submitting an empty block, should the user:

  • be required to confirm the empty block (similar to blocking self)
  • just not be able to block

My vote is that it would be stopped, something along the lines of "no blocking option was specified"

My vote is that it would be stopped, something along the lines of "no blocking option was specified"

+1 to this. I can't think of a reason someone would want to make an empty block.

DannyS712 lowered the priority of this task from Medium to Low.
Restricted Application added a project: User-DannyS712. · View Herald TranscriptApr 30 2020, 10:32 PM
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Apr 30 2020, 10:33 PM

Change 593871 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Prohibit empty blocks

https://gerrit.wikimedia.org/r/593871

@DannyS712 Are you going to make a separate patch about blocking empty blocks via the API?

@DannyS712 Are you going to make a separate patch about blocking empty blocks via the API?

The patch also prevents empty blocks via the API - internally ApiBlock just calls SpecialBlock::processForm

@DannyS712 Are you going to make a separate patch about blocking empty blocks via the API?

The patch also prevents empty blocks via the API - internally ApiBlock just calls SpecialBlock::processForm

Ah, got it. Thanks for explaining.
Unrelated but it seems like in an ideal world the form would be calling the API, not the other way around. ¯\_(ツ)_/¯

Ah, got it. Thanks for explaining.
Unrelated but it seems like in an ideal world the form would be calling the API, not the other way around. ¯\_(ツ)_/¯

We've actually been talking about creating a generic service to handle blocking / unblocking that is abstracted from either. :)

aezell added a subscriber: aezell.Mon, May 11, 5:54 PM

We've actually been talking about creating a generic service to handle blocking / unblocking that is abstracted from either. :)

Yes, we have. But, @DannyS712, that shouldn't block or delay this patch at all. It's just conversation at this point.

Change 593871 merged by jenkins-bot:
[mediawiki/core@master] Prohibit empty blocks

https://gerrit.wikimedia.org/r/593871

@DannyS712 With $wgBlockAllowsUTEdit set to false, if I try to submit an empty block I get the exception:
ErrorException from line 889 of /vagrant/mediawiki/includes/specials/SpecialBlock.php: PHP Notice: Undefined index: DisableUTEdit

That option removes the Editing their own talk page check box. I guess you need to test whether it is set first.

@Niharika I can create an empty block via the API by POSTing a non-existent page, e.g.:

action: block
partial: true
pagerestrictions: <non-existent page>
allowusertalk: true
autoblock: true
user: <target>
expiry: infinite

Does this matter?

Change 596612 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Prohibit empty blocks: fix for false $wgBlockAllowsUTEdit

https://gerrit.wikimedia.org/r/596612

Change 596612 merged by jenkins-bot:
[mediawiki/core@master] Prohibit empty blocks: fix for false $wgBlockAllowsUTEdit

https://gerrit.wikimedia.org/r/596612

@DannyS712 With $wgBlockAllowsUTEdit set to false, if I try to submit an empty block I get the exception:
ErrorException from line 889 of /vagrant/mediawiki/includes/specials/SpecialBlock.php: PHP Notice: Undefined index: DisableUTEdit

That option removes the Editing their own talk page check box. I guess you need to test whether it is set first.

Good catch!

@Niharika I can create an empty block via the API by POSTing a non-existent page, e.g.:

action: block
partial: true
pagerestrictions: <non-existent page>
allowusertalk: true
autoblock: true
user: <target>
expiry: infinite

Does this matter?

I can't think of why someone would do that. Especially as only privileged users have access to the block form. I think it's fine.

Isn't the issue with that that the partial block API accepts invalid pages? I think it matters but it'd be a different task.

Isn't the issue with that that the partial block API accepts invalid pages? I think it matters but it'd be a different task.

I think so, yes. My presumption is that this would be an edge case but yeah, it should be a different task nonetheless.

Niharika closed this task as Resolved.Wed, May 20, 12:09 AM