Page MenuHomePhabricator

Allow users to be blocked from uploading files only
Open, MediumPublicFeature

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.


Acceptance criteria

  • On Special:Block, under 'Actions to block' add a checkbox for Uploading files
    • The checkbox should be unchecked by default
    • The checkbox should be marked as disabled unless the 'Partial' radio button is selected
    • If a user toggles either the 'Editing' checkbox or the Sitewide/Partial radio buttons, the checkbox should save whatever state the user configured it as. The state can be discarded on submit if the block is non-editing or sitewide.
  • 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
    • e.g. 23:20, 26 November 2018 AdminUsername (talk | contribs | block) blocked BadUser (talk | contribs) from editing Page(s) and uploading files with an expiration time of N (autoblock disabled) (unblock | change block)
    • e.g. 23:20, 26 November 2018 AdminUsername (talk | contribs | block) blocked BadUser (talk | contribs) from uploading files with an expiration time of N (autoblock disabled) (unblock | change block)
    • similar log messages should exist for modifying blocks to add or remove upload, and to include namespaces within the partial block
  • Special:BlockList should display that a user is blocked from uploading files as a bullet in the 'Block parameters' column

Designs


  • Error message

    For Special pages:

    <strong>Your username or IP address has been blocked from uploading files. You can still edit other pages on this wiki.</strong> You can view the full block details at [[Special:MyContributions|account contributions]].
    
    The block was made by $1.
    
    The reason given is <em>$2</em>.
    
    * Start of block: $8
    * Expiration of block: $6
    * Intended blockee: $7
    * Block ID #$5

    For the in-editor tools:

    This error message appears on upload failureMessages appear on opening of the tool.
    AcceptablePreferred
    You have been blocked from uploading files.

    If we can add links to this error message, we should add a 'Details.' link which points to Special:BlockListwpTarget=USERNAME

    Details

    Reference
    bz4995

    Event Timeline

    There are a very large number of changes, so older changes are hidden. Show Older Changes

    robchur wrote:

    Bureaucrats can't do free changes to user group memberships on Wikimedia sites;
    via MakeSysop, they can add users to the sysop and bureaucrat groups, and via
    MakeBot, they can add or remove users to/from the bot group.

    We'd need a reliable backend method (fiddling with permissions wouldn't work,
    per comment 5 et al) and a frontend we could *use*.

    cohesion wrote:

    This would be useful on enwiki also, for the same reasons. I wouldn't want to
    limit to bureaucrats though.

    Possibly part of bug 674. I'm thinking of blocking users from Special:Upload, or something like that.

    I intend to make an overhaul of blocking, integrating it with protection and allowing very general, and very granular blocks. Per-permission blocking is an intended part of these changes, and will solve this bug.

    shinywater wrote:

    There's one thing I don't understand:

    Users ''can'' be blocked from emailing (i.e. the Special:Emailuser function is disabled for them)
    Users ''cannot'' be blocked from uploading (i.e. the Special:Upload function would be disabled for them)

    Why can't this be implemented?

    ayg wrote:

    It can be, just nobody's done it. Werdna is apparently working, or thinking of working, on a much more robust blocking system that should allow any number of things to be blocked separately, so I'd say this will more likely than not be fixed within a few months, but no saying for sure.

    demon added a comment.Jul 16 2007, 5:02 PM

    (In reply to comment #11)

    There's one thing I don't understand:

    Users ''can'' be blocked from emailing (i.e. the Special:Emailuser function is
    disabled for them)
    Users ''cannot'' be blocked from uploading (i.e. the Special:Upload function
    would be disabled for them)

    Why can't this be implemented?

    In addition, it's impossible to *just* block Special:Emailuser. That's an additive block, such that they're already blocked, and you block their access to e-mail in addition to it. Just as autoblock is additive. So to implement it in that fashion (which would be easy) is exactly against what you're suggesting.

    *** Bug 6670 has been marked as a duplicate of this bug. ***

    mike.lifeguard+bugs wrote:

    (In reply to comment #7)

    Bureaucrats can't do free changes to user group memberships on Wikimedia sites;
    via MakeSysop, they can add users to the sysop and bureaucrat groups, and via
    MakeBot, they can add or remove users to/from the bot group.

    We'd need a reliable backend method (fiddling with permissions wouldn't work,
    per comment 5 et al) and a frontend we could *use*.

    We're using Special:UserRights for everything now, but I'm not sure that's the best way to go about this - it should be integrated into blocking, not into user rights.

    Can't this be implemented using $wgRevokePermissions?
    Just add

    $wgRevokePermissions['blockedfromupload']['upload'] = true;

    or something like that (haven't tested the exact syntax) and add users to be blocked to the blockedfromupload group.

    On second thought, this solves only one half of the problem, because there's no way to automatically remove someone from a group after (say) 30 days. So it's not possible to completely emulate expiring blocks that way. Or did I overlook something?

    Not a seriois problem for commons, since we could have the users request their upload rights being restored (and thus review that they actually fixed their images).

    demon added a comment.Oct 22 2009, 4:31 PM

    I don't really consider that a solution, moreso a workaround (TBH, I never liked the idea of $wgRevokeGroups anyway, but I digress...)

    What we really need is to finally rewrite blocking to be permission-based.

    WONTFIX per http://toolserver.org/~mwbot/logs/%23mediawiki/20100323.txt
    Just a waste of everybody's time, developers and wiki users.

    Bryan.TongMinh wrote:

    For enwiki perhaps, but not for Commons. Reopening.

    As I said in channel, this is technically feasible after bug 14636 is done. It just happens to be really low priority.

    Note to potential patch contributors: Do NOT implement this like e-mail blocking was. Tacking another single-purpose column onto the ipblocks table is a Bad Idea. See the blocker if you really want to do this right. Thus, this is resolved LATER until that time.

    rd232 wrote:

    (In reply to comment #22)

    As I said in channel, this is technically feasible after bug 14636 is done. It
    just happens to be really low priority.

    Note to potential patch contributors: Do NOT implement this like e-mail
    blocking was. Tacking another single-purpose column onto the ipblocks table is
    a Bad Idea. See the blocker if you really want to do this right. Thus, this is
    resolved LATER until that time.

    Just to point out that while this may be "really low priority" for most wikis, that is not true for Wikimedia Commons. COM:BUGS lists it as a priority, noting "This is desirable to force users to correctly annotate their existing images and read the [[Commons:licensing|licensing]] rules before uploading any additional images."

    brion added a comment.Nov 29 2011, 9:42 PM

    Reopening; seems sensible in this day and age.

    prog4life wrote:

    I am considering looking into this, but can someone tell me why the example given in Comment 16 is not a solution to this?
    $wgRevokePermissions['blockedfromupload']['upload'] = true;

    prog4life wrote:

    Or at least a semi-solution if we assume that bureacrats do this job manually.

    (In reply to comment #25)

    I am considering looking into this, but can someone tell me why the example
    given in Comment 16 is not a solution to this?
    $wgRevokePermissions['blockedfromupload']['upload'] = true;

    Did you see my objections in comment 19?

    vvv added a comment.Apr 26 2012, 11:44 AM

    Russian Wikipedia implements this by automatically giving out a revokable uploader flag.

    Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 9 2015, 5:20 AM
    Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:03 PM
    Man77 added a subscriber: Man77.Dec 22 2015, 6:44 PM
    demon removed a subscriber: demon.Mar 9 2017, 9:42 PM
    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
    Liuxinyu970226 updated the task description. (Show Details)
    Liuxinyu970226 added a subscriber: Liuxinyu970226.
    Zest added a subscriber: Zest.Nov 16 2017, 1:28 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.

    TBolliger updated the task description. (Show Details)Oct 4 2018, 6:45 PM

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

    TBolliger added a comment.EditedOct 4 2018, 7:00 PM

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

    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:

    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?

    Restricted Application added a project: User-DannyS712. · View Herald TranscriptApr 12 2020, 7:27 PM
    DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Apr 12 2020, 7:28 PM

    @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 added a comment.EditedApr 12 2020, 7:33 PM

    @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