Change Details

Steps to reproduce: * As an admin, block a user, enabling the autoblock option * Set `$wgAutoCreateTempUser['enabled'] = true;` * As a logged-out user, try to edit an article from an IP address that was autoblocked * Expected: see an autoblocked notice * Actual: see no indication that there is a block Note: The block is enforced once the edit is submitted. However, the temporary user does not get any warning that they are blocked until that point.

==== Background Steps to reproduce: * As an admin, block a user, enabling the autoblock option * Set `$wgAutoCreateTempUser['enabled'] = true;` * As a logged-out user, try to edit an article from an IP address that was blocked * Expected: see an blocked notice * Actual: see no indication that there is a block Notes: 1. The block is enforced once the edit is submitted. However, the temporary user does not get any warning that they are blocked until that point. 2. This applies to direct blocks against the IP, autoblocks, and global blocks ==== Acceptance criteria With `$wgAutoCreateTempUser['enabled'] = true;`, and as a logged-out user visiting an edit page: * If there is a block against the user's IP address, they see a blocked notice above the editor * If there is an autoblock against the user's IP address, they see a blocked notice above the editor * If there is a global block against the user's IP address, they see a blocked notice above the editor * With `$wgGroupPermissions['*']['edit'] = false;`, and no block against the IP address, it is still possible to make an edit as a logged-out user since a temporary account will be created The final point is a regression check, since the code that introduced this bug was designed to implement that behaviour.

==== Background Steps to reproduce: * As an admin, block a user, enabling the autoblock option * Set `$wgAutoCreateTempUser['enabled'] = true;` * As a logged-out user, try to edit an article from an IP address that was autoblocked * Expected: see an autoblocked notice * Actual: see no indication that there is a block Note:s: 1. The block is enforced once the edit is submitted. However, the temporary user does not get any warning that they are blocked until that point. 2. This applies to direct blocks against the IP, autoblocks, and global blocks ==== Acceptance criteria With `$wgAutoCreateTempUser['enabled'] = true;`, and as a logged-out user visiting an edit page: * If there is a block against the user's IP address, they see a blocked notice above the editor * If there is an autoblock against the user's IP address, they see a blocked notice above the editor * If there is a global block against the user's IP address, they see a blocked notice above the editor * With `$wgGroupPermissions['*']['edit'] = false;`, and no block against the IP address, it is still possible to make an edit as a logged-out user since a temporary account will be created The final point is a regression check, the temporary user does not get any warning that they are blocked untilsince the code that introduced this bug was designed to implement that pointbehaviour.