User:Robchurch/Blocking Mechanism/Notes

Blocking edit

When a user is blocked, we should do two main steps:

  • Block the user
  • Block their IP addresses

These are refined below.

Block the user edit

This is simple. Add an explicit block on said user to the blocks table, expiring at X with reason Y.

Block their IP addresses edit

If recent changes has IP addresses in it, i.e. if $wgPutIPinRC is on, then obtain all the IP addresses a user has edited from within the past 24 hours and add explicit blocks on each, expiring at X (where X is 24 hours or less, otherwise we need to expire in 24 hours) with reason Z (something like the current autoblocker reason).

The IP address block isn't logged in Special:Log and is marked as an autoblock within the blocks table. When viewing the block list, the block identifier is used as normal.

There's scope for improving this; we could extend the time period to check IP addresses in to 48 hours, although this could cause collateral damage.

Effects edit

We'd replace the current User::isBlocked() function set in such a manner that the effects of a block depend upon the existence of a hard or a soft block.

Hard block edit

A user is hard blocked if:

  • Logged on; explicit block on account present

OR

  • Logged on; explicit block on IP address present (and the block is marked as hard)

OR

  • Not logged on; explicit block on IP address present


A user cannot edit while a hard block is in effect.

Soft block edit

A user is soft blocked if

  • Not hard blocked

BUT

  • Logged on and autoconfirmed; explicit block on IP address present

In these cases, we can control what happens in a number of ways. In core code, we could make it so that a block can be marked as hard (selected when blocking, defaults to soft, and is perhaps out of the control of normal administrators).

We could, for example

  • Throttle soft-blocked edits
  • Require soft-blocked edits to pass a captcha (using ConfirmEdit extension if available)

I'd suggest that the default effects of a soft block would be allowing the user to edit, but

  • Informing the user of the soft block at the top of the edit form
  • Not marking the edit as patrolled (when patrolling is on, with respect to the autopatrol UPO)