Page MenuHomePhabricator

Allow a user to be blocked from moving/renaming pages
Open, Stalled, Needs TriagePublicFeature

Description

Some users can cause disruption by moving/renaming pages.

Social sanctions can keep them in check, but currently the only technical means to corral this type of behavior is a full site block, which is extreme for some situations.


Request change

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 11 2018, 7:07 PM

I think this should just be a collection of any actions that someone is blocked from, could be "move" but might as well be any blockable action (upload, thank, sendemail (migrate from existing system), etc)

Vvjjkkii renamed this task from Allow a user to be blocked from moving/renaming articles to q3caaaaaaa.Jul 1 2018, 1:10 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
WhitePhosphorus renamed this task from q3caaaaaaa to Allow a user to be blocked from moving/renaming articles.Jul 1 2018, 2:40 AM
WhitePhosphorus raised the priority of this task from High to Needs Triage.
WhitePhosphorus updated the task description. (Show Details)
WhitePhosphorus added a subscriber: Aklapper.
DannyS712 added a subscriber: DannyS712.EditedAug 13 2019, 4:56 AM

I think this should just be a collection of any actions that someone is blocked from, could be "move" but might as well be any blockable action (upload, thank, sendemail (migrate from existing system), etc)

The easiest (existing) way to do this would be using [ $wgRevokePermissions ](https://www.mediawiki.org/wiki/Manual:$wgRevokePermissions) - a partial block would be akin to a temporary assignment of user rights.

To block someone from moving a page:, add them to a group (eg revoke-move) with $wgRevokePermissions['revoke-move']['move'] = true; For upload, sendemail, etc. this could work. For thank, however, there doesn't seem to be a right required for that.

@TBolliger Any comment in response to Danny's above suggestion? Sounds like blocking someone from moving a page is a simpler option to build in, similar to the block email option, and wouldn't require a database change.

@TBolliger Any comment in response to Danny's above suggestion? Sounds like blocking someone from moving a page is a simpler option to build in, similar to the block email option, and wouldn't require a database change.

What I proposed would actually require that a new user group be built (i.e. "users blocked from moving pages") and adding users to that would be akin to blocking them from moving. That was just a work-around, and probably isn't a good idea for wmf wikis (elsewhere, until the feature is available, it works though)

TBolliger no longer works for the WMF. As such, his account has been locked. But I am not sure why someone hasn't disabled the phabricator account yet. If I am not mistaken, an user can not use their account when it is locked and that includes using OAuth to login to other services (such as Phabricator). The current product manager is @Niharika. She might want to comment here instead.

Hi all. Just catching up on the ticket here. Thanks for tagging me @Masumrezarock100.
I think this is a good idea and I like @DannyS712's suggestion. I'll keep this on our radar when we wrap up our ongoing work on CheckUser and decide to come back to working on partial blocks.

Xaosflux changed the subtype of this task from "Task" to "Feature Request".Jan 14 2020, 7:38 PM
Jony added a subscriber: Jony.Jan 15 2020, 6:56 AM
DannyS712 changed the task status from Open to Stalled.Apr 12 2020, 7:34 PM
DannyS712 claimed this task.

Stalling pending product approval

Restricted Application added a project: User-DannyS712. · View Herald TranscriptApr 12 2020, 7:34 PM
DannyS712 moved this task from Unsorted to Next on the User-DannyS712 board.Apr 12 2020, 7:35 PM
Ammarpad removed a subscriber: Ammarpad.Apr 12 2020, 7:58 PM

@DannyS712 thanks for claiming, though I'd much rather all these one-offs be able to be done in one resolution as suggested at [[T242541]] if there is support for that strategy

@DannyS712 thanks for claiming, though I'd much rather all these one-offs be able to be done in one resolution as suggested at [[T242541]] if there is support for that strategy

Each of these needs separate approval, and some may be approved while others not, but the code will be similar, yes

I mean from a UX/UI point of view as well - instead of an endless series of checkboxes, use a list format for disallowed actions perhaps. Possibly populate from an array of valid actions, then future adds would just be to grow that array.

QEDK renamed this task from Allow a user to be blocked from moving/renaming articles to Allow a user to be blocked from moving/renaming pages.Apr 13 2020, 6:21 AM

Stalling pending product approval

On my list! Will get back to you soon. Thanks a lot!

There's an issue here we should account for, or at least be aware of, that may make this block action less impactful than we'd think. If we go with @DannyS712 idea, we could probably block the actual action of moving a page (when you hit the menu action item for "move") but there are other ways to move pages manually.

For example, say that I want to move the page "Foo" to the new page "Bar". I am blocked from the move action, so I can't use the move operation with the form. Okay, instead, I do this:

  • Copy the contents of "Foo"
  • Start a new page, "Bar", and paste in all of the contents of "Foo"
  • Edit "Foo" and add a manual redirect to "Bar"

This will not be an actual move (doing this means you lose the history) but it is, effectively, moving a page. We can't really block this operation unless the user is also blocked from creating new pages or editing the "Foo" page.

We have a couple of issues that are similar to this in MediaWiki, most of them are due to the fact that there can be multiple ways to perform actions; the actual "action" isn't really covering the process in general, which makes it really challenging (if at all possible) to completely block or control access to these user actions. Another example of this type of complexity is in "reverts" where you can revert an edit in multiple ways, and the actual action itself is not singular, or even very consistent (we have machine-learning type systems that try to categorize edits that are reverts, because it's so non trivial)

All of this is to suggest that we need to examine whether blocking the action (meaning really only being able to block the actual move through the menu/form) is enough. If the user can still basically effectively move pages by recreating them, is that still okay? Are we "promising" (with this feature) a block that we are actually not quite giving admins, and would that create more problems?

@Mooeypoo partial blocks already support blocking editing/creating as an action; and most projects will speedily delete pages that copy-and-paste as copyright issues. This is solely about the permission, as there have been instances where users are disruptive - but only about using the 'move' function - where prior to partial blocks would have been remedied with a traditional site block.

Users who are subject to a partial block from editing will be being watched to see if they are circumventing the block by copy-paste moves (at least on large projects). If they do that, then their actions can and will be reverted by others and they will be subject to increased sanctions. As long as the documentation of the feature mentions that there are workarounds (ideally bearing in mind WP:BEANS) then I don't see this as blocker to implementation.

MJL added a subscriber: MJL.Jun 1 2020, 8:07 PM

@Xaosflux @Thryduulf Good to know. Thanks for explaining that.

DannyS712 moved this task from Next to Later on the User-DannyS712 board.Jun 5 2020, 9:01 AM

->later pending official product approval to proceed

@DannyS712 I'm sorry it took so long to get back to you on this. I chatted with @Tchanders (who has expertise on blocking) and @Prtksxna (who has expertise in design) about this task and other related tasks. There are a few things we are thinking:

  1. We have been seeing more and more blocking-related requests come in (all of which you already know): T199918, T6995, T242785, T194529 etc. @Tchanders suggested a better technical approach to do this (with a new block_actions table) rather than implementing one-offs every time a new request comes in which would make the system more complex and fragile. That is what was proposed in T242541: Allow partial blocks against specified actions as well. We are currently looking at fleshing out the work needed to be done in that ticket. I would love to hear your thoughts about this.
  2. On the design front, there is a concern about adding more and more checkboxes to the page which expands as more options come in. We have seen community members be unhappy when the partial blocks options made the page longer, forcing people to scroll which reduced their efficiency. In addition to that, some options in the page are subset of or linked to other block options and it is not intuitive in the design that that is the case. While we were originally thinking of just adding more checkboxes (M300), we are not so sure about that with so many new options to be added to that page. We are thinking about how we can make the block page simpler while also having the ability to allow people to add more blocking options when needed. This could be a RecentChanges-style dropdown with checkboxes or something else.

@DannyS712 I'm sorry it took so long to get back to you on this. I chatted with @Tchanders (who has expertise on blocking) and @Prtksxna (who has expertise in design) about this task and other related tasks. There are a few things we are thinking:

  1. We have been seeing more and more blocking-related requests come in (all of which you already know): T199918, T6995, T242785, T194529 etc. @Tchanders suggested a better technical approach to do this (with a new block_actions table) rather than implementing one-offs every time a new request comes in which would make the system more complex and fragile. That is what was proposed in T242541: Allow partial blocks against specified actions as well. We are currently looking at fleshing out the work needed to be done in that ticket. I would love to hear your thoughts about this.

For page creation, I think it makes sense to continue with the current schema of ipblocks_restrictions with a new type for creating pages in a namespace (i.e. separate restrictions for creating pages in a namespace and editing in a namespace, but both can be applied per-namespace)

For the other actions (upload/move/thank), agree that it would be more future-proof for a separate table. Perhaps (haven't looked into if it would work):

block_actions
CREATE TABLE /*_*/block_action (
  baction_id smallint PRIMARY KEY AUTO_INCREMENT,
  baction_name varbinary(64) NOT NULL
) /*$wgDBTableOptions*/;
CREATE UNIQUE INDEX /*i*/baction_name ON /*_*/block_action (baction_name);

This would follow the same schema of the existing name tables (https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema#Name_Tables)

we would then have a new ir_type for actions (if 3 is for page creation by namespace, then 4), and would check

Query
SELECT baction_name AS `action`
FROM ipblocks_restrictions
JOIN block_action
ON baction_id = ir_value
WHERE ir_type = 4
AND ir_ipb_id = $blockId

to get a list of actions (as strings) that are blocked (i.e. move, upload, thank)

@DannyS712 Thanks for sharing your thoughts about action blocks. I agree that we might well want something along the lines of the block_actions table you've outlined.

As @Niharika said, I think we need to design the system before implementing for any particular action, so with that in mind, I've started to move this conversation over to T242541.

DannyS712 removed DannyS712 as the assignee of this task.Sep 22 2020, 8:37 PM

Avoiding cookie licking pending product approval

Niharika added a comment.EditedSep 25 2020, 9:42 PM

Avoiding cookie licking pending product approval

I was under the impression that we were going to tackle T242541: Allow partial blocks against specified actions first. I think @Tchanders' patch on that task is only a proof of concept. @Tchanders what would you recommend as the path forward?