Page MenuHomePhabricator

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

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

    bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:05 PM
    bzimport added a project: MediaWiki-Uploading.
    bzimport set Reference to bz4995.
    bzimport added a subscriber: Unknown Object (MLST).
    bzimport created this task.Feb 15 2006, 7:43 AM

    brianna.laugher wrote:

    Maybe related to [http://bugzilla.wikipedia.org/show_bug.cgi?id=1535], a request
    to block users from specific namespaces only.

    Also, if it's helpful, I'm [[commons:User:pfctdayelise]].

    dbenbenn wrote:

    (In reply to comment #1)

    Maybe related to [http://bugzilla.wikipedia.org/show_bug.cgi?id=1535], a request
    to block users from specific namespaces only.

    Just to clarify, this request is not actually the same as bug 1535. We
    specifically want to allow people to edit image pages (so they can add the
    source information for their uploads, for example) without being able to upload
    new images.

    When implementing this, think in adding an autoconfirmed-required-for-upload
    feature.

    The suggestion in that post wouldn't work; permissions from groups
    are additive so the default permission would always override it.

    brianna.laugher wrote:

    Is it possible to implement this only on Commons, if nothing else? Can we not
    create a user group that is exactly the same as users at the moment except they
    can't upload?

    Bureaucrats can change user groups, right? Even if only bureaucrats could do
    this, it would still help. We have some active bureaucrats now.

    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 moved this task from Untriaged to Backlog on the Anti-Harassment board.
    TBolliger raised the priority of this task from Lowest to Normal.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:

    TBolliger updated the task description. (Show Details)Nov 27 2018, 11:41 PM

    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.