- On wiki that has RC filters enabled, select 'Wikidata edits ' and 'Unregistered'
- The above filters selection shows wikidata registered users ; 'Wikidata edits' and 'Registered' will return no results.
The screenshot is from plwiki:
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Good catch.
The propagated edits are all marked as unregistered, presumably since the user IDs are different between Wikibase and the local wiki: https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/client/includes/RecentChanges/RecentChangeFactory.php;9af569f795a8a161af36310f0f6c82e115529bab$118 .
We should register a conflict for this.
Comment Actions
It looks like the edits in Elena's screenshot are actually by registered users but MARKED as unregistered. So what is the fix suggested here? Are we going to make it so that the system recognizes registered users?
If so, why does Matt want to register a conflict? Or is that just until we can make the above fix?
Comment Actions
I was suggesting to register the conflict as the solution. There's a couple solutions I can think of, and there might be others.
- Try to propagate the rc_user value itself; requires transforming it since the user ID on Wikidata is not the same as the user ID on other wikis (e.g. enwiki). Need to consider edge cases of users not being attached (should be extremely rare now).
- Register conflict.
I also considered using rc_user_text for the Registered/Unregistered filter, but that probably isn't feasible, since rc_user_text is used for IP address as well, and an SQL query can't distinguish.
Comment Actions
@Catrope and I discussed an alternative he came up with, setting rc_user to -1 for logged in users, but we both like #1 better. We can just leave it as 0 for the edge case where either the Wikidata user or the client user isn't attached.
Unfortunately, there is no method in CentralIdLookup to get a central user ID for a foreign wiki. But we can add the central user ID to change_info in wb_changes.