(WAS:New option to allow confirmed users to edit from IPs targeted by proxy blocks)
Forked from T323948: Blocking all non-confirmed users on an IP or IP range (aka range block against sleeper accounts). "confirmed users" means those with autoconfirmed right, which are not considered “newbies” for purposes of User::isNewbie().
Note:
There is no such thing as a "proxy block", so is this a request to create a new block flag? I can't see why it would need to be so specific to the underlying reason of the block either, as opposed to the ticket this was split from. (i.e. if you want to make a block for non-confirmed, building software to differentiate why one of those non-confirmed blocks is technically different from another one seems like overkill -- the block reason can already explain the block motive).
AIUI, this task would benefit from doing T352148: Block schema: add a structured category/reason_type field first. So, e.g.
So there wouldn't need to be an additional "option to allow confirmed users to edit from IPs targeted by proxy blocks" - if the blocker wanted them to edit in a block they classified as an "open proxy" block they just wouldn't apply it to confirmed users (what T323948 would create)? And doing T323948 could achieve this even if T352148 never completes. Point being I don't think we would need to build another technical check.
Agree, we just need a third block option next to anon-only vs. hard block, which targets anon + non-confirmed users.
I'm going to call this task itself WONTFIX, as the idea would be accomplished by T323948; which could be used for this or any other reasons as desired by administrators. "Proxy" blocks are already administratively considered in some cases if they should apply to everyone or just unregistered accounts, applying to "not confirmed" or not could still be an option that admins could choose, even if a block category were introduced, and "proxy" was the the type. Discussions about when certain blocks should be used can stay with communities and their representative administrators.
Reopening, but redefining - as T323948 is about "blocks", we can keep THIS ticket for the same concept for "globalblocks" - however, it should be expanded to the same use case, not ONLY "proxy" blocks.
There can be all sorts of use cases for when to exempt confirmed users from a range block - but a general implementation would solve for the original story.