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

In T208645#4720256, @dbarratt wrote:

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?

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?

@dbarratt see https://test.wikipedia.org/wiki/Special:Log?type=&user=Xaosflux&page=User%3AXaosflux2&wpdate=&tagfilter=

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.

In T208645#4722872, @Xaosflux wrote:

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

In T208645#4722945, @TBolliger wrote:

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.

In T208645#4722971, @TBolliger wrote:

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

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.

Deprioritizing new feature development on Partial Blocks in 2019 by the WMF's Anti-Harassment-Team 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.

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

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.

In T208645#5815547, @DonTrung wrote:

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

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

In T208645#6098398, @Niharika wrote:

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

In T208645#6098787, @Xaosflux wrote:

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.

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

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

Thanks @DannyS712. Anti-Harassment-Team can help review this.

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

In T208645#6123043, @Niharika wrote:

@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

In T208645#6123145, @DannyS712 wrote:

In T208645#6123043, @Niharika wrote:

@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. ¯\_(ツ)_/¯

In T208645#6123245, @Niharika wrote:

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

In T208645#6125684, @dbarratt wrote:

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

In T208645#6139831, @dom_walden wrote:

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

In T208645#6142210, @Amorymeltzer wrote:

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.

(belated but) I think that's T213837