Last modified: 2005-10-19 06:55:10 UTC
For example, if User:trollinator is blocked for 24 hours at 1005 Sunday and clicks on a broken link at 0955 Monday, the IP address she is using is blocked until 0955 Tuesday.
Possibly related to bug 1156, bug 1204
It should be noted that this bug was there from the very beginning. It is a known design flaw (I believe bug 1204, at least, is new).
Is this a bug or intended behavior?
This is a bug. People are regularly blocked for longer than originally intended because of this bug. I get emails about it all the time. A better behaviour would be to autoblock the IP for a length of time that would expire at the same time as the original block, but with a maximum (such as 24 hours).
*** Bug 1888 has been marked as a duplicate of this bug. ***
I would have raised this as critical prio. Smaller wikipedias don't have admins online 24/7 and longer-than-required blocks may raise significant noise.
The effect of this bug is to reset a user's block from the start whenever they click "edit this page". However, as I understand it, users do not find out *by software* that they are blocked until they actually go to this edit page. As a result, their block does not always technically start until they actually try to edit. And if they go back to an edit page to re- read their block information (such as to get the name of the blocking administrator) the block starts again on their current IP address. As far as I know, this is not the intended effect of blocks.
I should add that this happens even when you're logged in under the username that was originally blocked (logged in as User:trollinator). I'm not sure if this should require a different report or not, but it would be helpful to display a 'view source' that displays the source since they can't edit at the time (same as when a page as protected). Yes, you can get an xml dump of the page, from from a UI standpoint it makes more sense to have this option which the users are used to.
I've encountered this behavior in the past but have only gotten a real grasp on what is happening since I've examined the source code. The problem is in User::spreadBlock() which is executed when User::GetBlockedStatus() for a logged-in user determines that a user block is in progress. The function User::spreadBlock() then looks to see if the IP address is already blocked. If so, it calls Block::updateTimestamp(), which calls Block::getAutoblockExpiry() to calculate the new expiry time. After checking that the IP block was an autoblock, this simply adds the global constant $wgAutoblockExpiry to the timestamp. The default value of this constant is 86400, which programmers will recognise as the number of seconds in a day. By contrast, if the IP address was not already blocked, the autoblock expiry time is only set to time+86400 if this is earlier than the user block expiry time. This code should also be executed in Block::updateTimestamp(). I'm fixing this in my test wiki now.
(wikibugs-l@wikipedia.org needs to be added to the CC list when changing assignment.)
Created attachment 944 [details] Fixed the bug. Check if the auto-block excedes the user-block If auto-block excedes the user-block, then the auto-block would not be prolonged for another 24 hours.
Created attachment 952 [details] Patch for the fix cvs patch.
