Page MenuHomePhabricator

Allow users to be blocked from uploading files only
Closed, ResolvedPublicFeature

Assigned To
Authored By
bzimport
Feb 15 2006, 7:43 AM
Referenced Files
F34274815: image.png
Apr 7 2021, 2:26 PM
F26309436: Screen Shot 2018-10-04 at 12.02.51 PM.png
Oct 4 2018, 7:03 PM
F26309395: block notice in media upload.png
Oct 4 2018, 7:00 PM
Tokens
"Like" token, awarded by Riley_Huntley."Like" token, awarded by Liuxinyu970226."Like" token, awarded by Luke081515."Like" token, awarded by MGChecker."Like" token, awarded by Nemo_bis.

Description

Problem to solve

There are some problematic users who continually violate file upload policies & guidelines, but should otherwise be retained on the wiki as constructive contributors. A sitewide block is not an appropriate way to handle these situations.

Proposed solution

It would be useful to be able to *only* block users from uploading files.

Allowing them to keep editing allows them to contact people who can help explain copyright issues to them and shouldn't cause the same outrage that sitewide blocking tends to.

Mockup

image.png (1×1 px, 266 KB)

Acceptance criteria
  • On Special:Block, under 'Actions to block' add a checkbox for Uploading files
    • The checkbox should be unchecked by default with "Partial" block being selected
    • The checkbox should be checked and disabled if "Sitewide" block is selected
  • When a block is saved with the 'Uploading files' checkbox selected, the target user should not be able to upload files via API, via any tool in any editor, or via any Special page.
    • Error messages should display appropriately (see below)
      • Special:Upload
      • Special:UploadWizard
      • Uploading a file in an editor (visualeditor, 2017 source editor, or 2010 source editor.) — I believe they all use the same tool.
  • When a Partial block is saved with the 'Uploading files' checkbox selected, the log items should indicate uploading files is part of the block
  • Special:BlockList should display that a user is blocked from uploading files as a bullet in the 'Block parameters' column (covered in T279559)
  • If we can add links to this error message, we should add a 'Details.' link which points to Special:BlockListwpTarget=USERNAME

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
kaldari renamed this task from Ability to block users from uploading files or EmailUser only to Ability to block users from uploading files only.Jul 6 2017, 9:13 PM
TBolliger renamed this task from Ability to block users from uploading files only to Allow users to be blocked from uploading files only.Jan 12 2018, 11:49 PM
TBolliger moved this task from Backlog to User blocking on the MediaWiki-User-management board.
TBolliger raised the priority of this task from Lowest to Medium.Aug 24 2018, 4:06 PM
TBolliger updated the task description. (Show Details)
TBolliger removed a subscriber: wikibugs-l-list.

I've updated the ticket to include acceptance criteria. There are still some details that need to be filled in (what do the error messages look like in the editors? what do the log entries look like?)

The Anti-Harassment Tools team will take this ticket on in the coming months, after T2674: Allow users to be blocked from editing a specific article or all articles inside a namespace is complete.

I still need to test what the error messages are in the VE and Upload Wizard when a user is blocked.

If a user is blocked but uses the VisualEditor to upload a file, this is the error message that displays.

block notice in media upload.png (1×1 px, 250 KB)

The message is minimal and doesn't represent the full details of the blocks. We should probably update it, but we first need to determine the complexity of operating in the VE code base.

Alternatively, there is this message, which could be emulated for partially blocked users:

Screen Shot 2018-10-04 at 12.02.51 PM.png (922×1 px, 299 KB)

Some thoughts/opinions on the behavior of the checkbox:

  • The defaults for the pages and namespaces input fields are empty, so the default for other actions (upload, create page, etc.) should also be empty/unselected.
  • We should seek to avoid as much causal state-changing as possible.
  • The state of the checkbox is only relevant if the 'Partial' radio button is selected. If the box is unselected when a 'Sitewide' block is submitted, the block will still cover uploading. This is implied by the active/inactive state of the elements.

Ping @Prtksxna to review this ticket and share his opinion on my proposed acceptance criteria.

  • The defaults for the pages and namespaces input fields are empty, so the default for other actions (upload, create page, etc.) should also be empty/unselected.

I agree, when the block is partial the user should have to explicitly mark all the things that the user is blocked from.

  • The state of the checkbox is only relevant if the 'Partial' radio button is selected. If the box is unselected when a 'Sitewide' block is submitted, the block will still cover uploading. This is implied by the active/inactive state of the elements.

Yeah, unchecking the Uploading files option if the user switches to Sitewide isn't helpful. I have two questions around this though:

  1. Do we also retain the values in the other fields? (I suppose yes)
  2. Did we consider hiding these options altogether (instead of just disabling them) when the Sitewide option is selected? (This might reduce some confusion, if any)

Yeah, unchecking the Uploading files option if the user switches to Sitewide isn't helpful. I have two questions around this though:

  1. Do we also retain the values in the other fields? (I suppose yes)
  2. Did we consider hiding these options altogether (instead of just disabling them) when the Sitewide option is selected? (This might reduce some confusion, if any)
  1. Yes, other field values are retained if a user switches.
  1. Our understanding is that hide/show is not part of the supported style guide, and that active/inactive is the preferred treatment. Is this not the case?
  1. Yes, other field values are retained if a user switches.

👍🏽

  1. Our understanding is that hide/show is not part of the supported style guide, and that active/inactive is the preferred treatment. Is this not the case?

Yep, we don't use that pattern anywhere else, was just wondering if we considered it for this. Happy to go ahead the way it is 🙂

This will require database changes. Putting on hold until we see that Partial Blocks are effective/impactful.

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.

Xaosflux changed the subtype of this task from "Task" to "Feature Request".Jan 14 2020, 7:38 PM
DannyS712 added subscribers: Niharika, DannyS712.

@Niharika any objections from Anti-Harassment / is this approved from a product point of view?

@DannyS712 Can I ask you to leave this and other Partial-blocks related tasks alone for a little while, while I go over them and make myself familiar with them? I was not the product manager when this project was being worked on and I need some time to understand them and prioritize them.
Thank you for your understanding.

@DannyS712 Can I ask you to leave this and other Partial-blocks related tasks alone for a little while, while I go over them and make myself familiar with them? I was not the product manager when this project was being worked on and I need some time to understand them and prioritize them.
Thank you for your understanding.

Sure; can you include T194529: Allow a user to be blocked from moving/renaming pages in your tasks to look over? I just claimed it, but will wait until approval before proceeding

->later pending official product approval to proceed

Avoiding cookie licking pending product approval

Niharika updated the task description. (Show Details)

@DannyS712 Hey, the AHT team is prioritizing work on this task, in addition to T199918: Allow a user to be blocked from creating pages only, T242785: Allow a user to be blocked from sending thanks and T194529: Allow a user to be blocked from moving/renaming pages. We have some newer engineers on the team and we think this would be a good project to onboard folks on Blocks. I hope you don't mind. Your comments and reviews are always welcome. :)

Change 679329 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@master] Introduce infrastructue for partial blocks for actions

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

Test wiki created on Patch Demo by TChan (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/043e527e89/w/

Change 679329 merged by jenkins-bot:

[mediawiki/core@master] Introduce infrastructure for partial blocks for actions

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

Blocking a user from uploading files blocks them from:

  • Special:Upload
  • API:Upload
  • Visual Editor and Source Editor upload (although they appear to just use API:Upload)
  • Upload Wizard (tested on Commons beta)

But not from any other action (that I tested).

I tested this for single and composite blocks and system blocks (the latter tested on my local docker).

Otherwise, I checked that previous blocking behaviour with respect to file uploads still occurs. You are blocked from uploading files if you are blocked sitewide or from the File namespace.

I checked that the new parameter is added and removed from the ipblocks_restrictions table as appropriate when adding/removing/editing blocks.

I also checked that rows are purged from the same table after the block has expired (after performing an action like adding a new block).

I wanted to test the scenario where, after having $wgEnablePartialActionBlocks enabled for a while, we have to turn it off for some reason. After we turn it off:

  • Entries in ipblocks_restrictions are untouched unless the block expires or is edited
  • Having an entry in the ipblocks_restrictions table on its own does not appear to block the user from uploading files

Throughout testing I kept an eye on beta logs. I could see no errors associated with our work.

For this, I did not test:

  • How blocks appear in Logs, Special:BlockList, CentralAuth, etc. (as we are dealing with in separate ticket)
  • Extensive UI testing of Special:Block (including cross-browser/mobile) (as we know there are some UI bugs and are fixing those separately)

N.B. I think I have covered all the ways to upload a file, but I am not sure. For example, I tried to use Special:Import to import an image from Commons. However, although it created the page in the File namespace, it did not upload the image (and reading https://www.mediawiki.org/wiki/Manual:Importing_XML_dumps, I don't think you can import images). A user has to have special rights to do this anyway, which could be removed from a blocked user.

EDIT I also briefly tested reuploading an already uploaded file. When blocked, I was not able to via Special:Upload, API:Upload (although I don't think it supports this anyway) or SVG Translate.

Test environments:

Test wiki on Patch Demo by TChan (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/043e527e89/w/