In T194529#4201905, @Xaosflux wrote:

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.

In T194529#5726800, @Riley_Huntley wrote:

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

@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

In T194529#6050852, @Xaosflux wrote:

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

In T194529#6050486, @DannyS712 wrote:

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.

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

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

In T194529#6208469, @Niharika wrote:

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

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

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.

In T194529#6485377, @DannyS712 wrote:

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?

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

[mediawiki/core@master] Allow users to be partially blocked from moving/renaming pages

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

Change 683623 merged by jenkins-bot:

[mediawiki/core@master] Allow users to be partially blocked from moving/renaming pages

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

Change 683948 had a related patch set uploaded (by DannyS712; author: DannyS712):

[mediawiki/core@master] Add comment from grep where ipb-actions-move is used

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

Change 683948 merged by jenkins-bot:

[mediawiki/core@master] Fix grep comments in BlockActionInfo for messages

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

I tested the behaviour of moving/renaming pages for a blocked user:

• If blocked from moving pages (either single or composite) they cannot move any page (via Special:MovePage or Api:Move)
• Otherwise, they cannot move to or from pages which they are blocked (I tested this for partial single and composite blocks, sitewide blocks I have tested a bit incidentally for T6995)

I did not see any errors in beta's logs.

The new rows in ipblocks_restrictions which correspond to this new action block appear to be cleaned up when the block is removed or expires.

I didn't test:

• System blocks
• Special:Block with the new action block options on browsers other than Firefox

The new infrastructure for action blocks has been/will be tested more thoroughly in T6995/T279556.

Test environment: https://en.wikipedia.beta.wmflabs.org MediaWiki 1.37.0-alpha (356bc14) 14:31, 3 May 2021.

Is this task actually resolved? There is nothing in the interface to indicate this can be done.

@Izno This work has been done, but partial action blocks aren't enabled everywhere yet. At the moment they're only enabled in the testing environments (T280528).

We did have a plan to enable it more widely, but it was put on hold when the team was asked to work on SecurePoll. @Niharika might be able to comment on our current plans?

Here's the task tracking wider deployment: T280531