Last modified: 2014-10-15 10:51:10 UTC
The RC filters doesn't work right: hideanons=1 overrules hidewikidata=0. That means, that wikidata entries are not shown, maybe handled as anonymous edits? I suggest that hideanons should not influence wikidate entries.
Yes, wikidata edits are assigned user id 0 in the recent changes table. This means they are treated as anonymous. We hope to improve this, of course.
@raimond: I agree of course, but I don't see a good way to do this. The user making the edit on wikidata may not have an account on the wiki where you are looking at recentchanges. So what user id could we used except 0? We could try -1 or some such magic value, but that's likely to break things elsewhere...
(In reply to comment #1) > Yes, wikidata edits are assigned user id 0 in the recent changes table. This > means they are treated as anonymous. Not only that, but all the other recentchanges data are fake, copied from the last row for the article in question; see also discussion after [06:55:43] in http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki/20130706.txt 0 is semantically correct but amount of non-standard RC entries Wikidata introduces pushes its usage to the limit (maintenance scripts edits and imported edits would normally not show up in RC anyway). Maybe you could just use the user ID of the user on Wikibase, this wouldn't have any bad practical consequence I can think of from the top of my head (it's ugly but those RC rows already are). A workaround could be to make RecentChanges check the username instead, with regexes to identify IPs, when non-default switches not excluding wikidata are selected.
*** This bug has been marked as a duplicate of bug 49315 ***
