In T111847#1620788, @Snowolf wrote:The behavior of this bug is quite odd. I noticed this a week or so ago when I was working on my stats tool but hadn't got around to properly reporting it.
If you look at the global rename log, entries for august and september are shown, but if you filter by records from August 2015 and older, a weird set of 5 entries from May 2015 is shown. This is the same ones, unless if the month is set to anything prior to May 2015, thenno records are shown.
Description
Description
Details
Details
Related Objects
Related Objects
Event Timeline
Comment Actions
This is similar to the query run when you go to that log query.
MariaDB [metawiki_p]> SELECT log_id,log_type,log_action,log_timestamp,log_user,log_user_text,log_namespace,log_title,log_params -> FROM `logging` LEFT JOIN `user` ON ((log_user=user_id)) -> WHERE log_type = 'gblrename' AND (log_timestamp<'20150901000000') -> ORDER BY log_timestamp DESC LIMIT 5; +----------+-----------+------------+----------------+----------+-------------------+---------------+--------------------------------------+--------------------------------------------------------------------------------------------+ | log_id | log_type | log_action | log_timestamp | log_user | log_user_text | log_namespace | log_title | log_params | +----------+-----------+------------+----------------+----------+-------------------+---------------+--------------------------------------+--------------------------------------------------------------------------------------------+ | 13203691 | gblrename | rename | 20150831230258 | 19465 | Maire | -1 | CentralAuth/CatLover1990 | a:2:{s:10:"4::olduser";s:13:"EmpireLabsInc";s:10:"5::newuser";s:12:"CatLover1990";} | | 13203685 | gblrename | rename | 20150831230230 | 19465 | Maire | -1 | CentralAuth/Lawrence_Horner | a:2:{s:10:"4::olduser";s:15:"Lawrence horner";s:10:"5::newuser";s:15:"Lawrence Horner";} | | 13202369 | gblrename | rename | 20150831212430 | 60929 | MBisanz | -1 | CentralAuth/Mthmpsn | a:2:{s:10:"4::olduser";s:8:"Iwu oirp";s:10:"5::newuser";s:7:"Mthmpsn";} | | 13201418 | gblrename | rename | 20150831200937 | 1181 | Céréales Killer | -1 | CentralAuth/LUIS_ZÚÑIGA_(Escritor) | a:2:{s:10:"4::olduser";s:9:"Luis2015Z";s:10:"5::newuser";s:24:"LUIS ZÚÑIGA (Escritor)";} | | 13200697 | gblrename | rename | 20150831190551 | 1181 | Céréales Killer | -1 | CentralAuth/Martin_Sugioarto | a:2:{s:10:"4::olduser";s:5:"Bugil";s:10:"5::newuser";s:16:"Martin Sugioarto";} | +----------+-----------+------------+----------------+----------+-------------------+---------------+--------------------------------------+--------------------------------------------------------------------------------------------+ 5 rows in set (0.05 sec)
That returns something during August as well.
But the actual query which is run does an inner join on log_search coming from CentralAuthHooks::onSpecialLogAddLogSearchRelations().
INNER JOIN `log_search` ON ((ls_log_id=log_id)) WHERE ls_field = 'oldname' AND ls_value = ''
This causes the results to be lost because there is no match.
Comment Actions
Change 239557 had a related patch set uploaded (by Glaisher):
Don't add unnecessary conditions on CentralAuthHooks::onSpecialLogAddLogSearchRelations
This comment was removed by Paladox.
Comment Actions
Change 239557 merged by jenkins-bot:
Don't query for oldname if none was provided in SpecialLogAddLogSearchRelations hook