Last modified: 2008-10-11 17:17:34 UTC
It appears that when some accounts are blocked with the "Allow user to edit own talk page" box checked, the user is nevertheless unable to edit their talkpage. An incident involving this is documented at <http://en.wikipedia.org/w/index.php?title=User_talk:Giano_II&oldid=242620844#Block_10.2F2> The problem appears to be intermittent and tests have not managed to reproduce the effect, so it is unclear how widespread this bug is.
I moved this to 'blocker', as it's really not good if admins are going to prevent talkpage use or not.
I isolated the problem - it only happens if the autoblock is enabled. Apparently the autoblock also inhibits editing one's own talk page, regardless of the settings of the original block.
I'm looking into this problem, but anything that could help me track it down is appreciated (log entries, pages that have been tested on, accounts blocked with it, anything else you can think of.)
More specifically, this seems to happen if the user has already been unblocked but the autoblock is still in place. I'd guess it probably also occurs if the user's IP has been blocked directly.
Oddly, while I can reproduce this on enwiki (running 41337), I still can't get it to happen on my test wiki (r41682). There's one change to the relevant code in between, r41403, but I can't see how that one could possibly make a difference here unless something really weird is going on in User.php.
...except that the _other_ part of r41403 is probably relevant indeed. It seems that Wikimedia, having run update.php between r41248 and r41403 (and indeed being still below r41403), has ipb_allow_usertalk bool set to default to 0. My test wiki, which I just upgraded to svn HEAD from an old revision, has it defaulting to 1. I think I've found the problem.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/41403
An update query has already been run on Wikimedia, to UPDATE retroactiveley (and also, User.php is individually synched to 41403 on Wikimedia). It is always set when inserting a block, so the default wont matter.
Ah yes, sorry. The change that actually fixed it appears to have been r41444.
In that case, looks like its fixed.
*** Bug 15938 has been marked as a duplicate of this bug. ***