Last modified: 2014-05-25 09:19:33 UTC
https://fr.wikipedia.org/w/index.php?title=Aide%3ALiens_internes&action=history&year=&month=-1&tagfilter=&deleted=1 The various IPs are getting hidden in a rather weird way, with no entries into the log. They are not blocked locally, or at least some aren't, and so there isn't any hideuser in place nor there is a global oversight (as that works only on accounts). It seems rather misterious how all these IPs, dating back to 2009, on this specific page get this treatment (which is suppression of the username/IP from those edits -- it can be manually undone by unticking the boxes, but there's no log of why they were hidden anywhere that we could find).
Indeed, this is a global problem on frwiki: all IP contributions made more than a few hours ago (before 2012-03-29 2:50 UTC at this time) appear as is they were hidden by oversight in all histories and lists of contributions. They are still visible in the list of recent changes, however.
Confirmed. Appears to be fr.wiki only, see for example fr.wikt OK at [1] and en.wp appears unaffected. Marking as a wikimedia issue for now and increasing priority. [1]: http://fr.wiktionary.org/w/index.php?title=naviguer&action=history
Interestingly enough, some IPs do not get hidden, see https://fr.wikipedia.org/w/index.php?title=Aide:Liens_internes&action=history (the 188.241.127.40 was unsuppressed by me to test stuff, but the other edits after seem not suppressed, this is most peculiar)
Apparently there was a bug in global suppression that caused this to happen when Snowolf suppressed a certain user via Special:CentralAuth on meta. Aaron has deployed a temporary fix and is working on a cleanup script at the moment.
Actually the account was suppressed via ApiBlock, not CentralAuth. I was just misled by the block summary. ApiBlock calls SpecialBlock::processForm(), which since r83810 has not properly validated its parameters. It doesn't notice when the user does not exist, blindly passing it through to Block::setTarget() and RevisionDeleteUser::suppressUserName(). The ipblocks row had a non-zero ipb_by which is not possible with CentralAuth. So I cross-referenced the event time with the logs, and sure enough, there was an api.php post to frwiki at the time in question.
I'm running a cleanup script.
We could have got the old rev_deleted values out of a snapshot if this was escalated early enough, but they only last 16 hours and it's been 31.
I don't know what the cleanup script does exactly (replay the suppress log, maybe?), nor if it has already finished running, so I apologize in advance if my comment is irrelevant. It seems to me that most of the hidden IPs are back, except when the visibility of a revision had actually been changed. For example in ¹ or ², some revisions were /deleted/ (only for the content) by a sysop, but they now appear as /suppressed/ (for both the content and the IP) as if they had been oversighted. Best regards, ¹ https://fr.wikipedia.org/w/index.php?title=%C3%89pisodes_de_Hollywood_Girls_:_Une_nouvelle_vie_en_Californie&action=history ² https://fr.wikipedia.org/w/index.php?title=F%C3%A9d%C3%A9ration_nationale_des_associations_d%27accueil_et_de_r%C3%A9insertion_sociale&action=history
Revisions by anonymous users which formerly had their rev_deleted flags set to DELETED_USER|DELETED_RESTRICTED (i.e. hidden user and suppressed) were temporarily visible. I've now searched the suppress logs and determined that 18 such revisions were given those flags at some point in the past, so I re-hid them with SQL. The remaining data corruption that I'm aware of is: * Revisions by anonymous users which previously had one or the other of the deleted flags (hidden user or suppressed) now have both. * Revisions by anonymous users which previously had both hidden user and suppressed, but were subsequently unhidden (rev_deleted=0), will now be rehidden. I don't know if there are any such revisions. If the remaining data corruption has little impact then I'd be happy to leave it as is. The flags can always be fixed by on-wiki actions if there is a reason to do that in some specific case.
Lowering priority since it looks like the emergency is over. I'll leave this to someone else to close.
Hi, Thanks for you help. > * Revisions by anonymous users which previously had one or the other of the deleted flags (hidden user or suppressed) now have both. I don't think this is a major issue. I suppose anonymous users are hidden for privacy reasons, so I doubt the suppressed flag could bother the sysops; and suppressed revisions being visible only with the oversight right, the user is visible too. > * Revisions by anonymous users which previously had both hidden user and suppressed, but were subsequently unhidden (rev_deleted=0), will now be rehidden. I don't know if there are any such revisions. If any, that shouldn't be a big issue either. Unfortunately, there is at least one other remaining corruption which is much more annoying: revisions which have had their rev_deleted flags set to DELETED_TEXT (ie. only the text has been deleted, and still visible to sysops) now have it set to DELETED_TEXT | DELETED_USER | DELETED_RESTRICTED . This prevents both regular users and sysops from knowing that a given anonymous user's edits were deleted. For example, if you look at ¹ without the oversight rights, you only see 9 edits, each of which looks legit. But if you have oversight rights, you can see 9 more edits which were deleted (*not* suppressed) because of blatant copyright violation. These revisions should be visible to sysops (user and text) and to regular users (user only) so that they can fight recurring copyright violation and identify long-term copyright violators and other vandals and sockpuppets (among other things). Other examples include the two links I have posted before (² and ³), where neither the regular users nor the sysops can check who is responsible of the edits that have been deleted nor if the deletion was justified. I'd be happy to help to fix the remaining issues if I can. Maybe by proposing relevant sql queries? Best regards, ¹ https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Contributions/82.230.44.141 ² https://fr.wikipedia.org/w/index.php?title=%C3%89pisodes_de_Hollywood_Girls_:_Une_nouvelle_vie_en_Californie&action=history ³ https://fr.wikipedia.org/w/index.php?title=F%C3%A9d%C3%A9ration_nationale_des_associations_d%27accueil_et_de_r%C3%A9insertion_sociale&action=history
still seems to be hidden per links above.
Any update on this? I still see the issues jroquet raised above.
The already existing data corruption, or some new problems with this?
There is no new problem, AFAIK, but the issue described above are not yet resolved. Best regards
Dear all, Orlodrim and myself are currently studying the possibility of fixing the remaining corruptions locally using a bot. I'm confident about our ability to do this without damage, but this will flood the oversight logs. Best regards an thanks again for your help.
Does this bug report still need to be open?
(In reply to Jérémie Roquet from comment #16) > Orlodrim and myself are currently studying the possibility of fixing the > remaining corruptions locally using a bot. I'm confident about our ability > to do this without damage, but this will flood the oversight logs. Any news? Is anybody actually still interested in fixing this (it's been two years now)?
Per https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Masqueur_de_modifications/Renouvellement#Nomination_d.27un_masqueur_.C3.A0_titre_provisoire - The French Wikipedia ArbCom have resolved to promote Orlodrim to Oversighter for the purpose of this bug. Assigned said user assuming they are working on it as it seems so from the request filed as SRP.
I confirm that I will work on this bug, following the approach previously explained by Arkanosis. This will generate about 5600 events in the suppression log.
This is now fixed. I changed the visibility of 37238 revisions in 5234 pages.
