Last modified: 2014-11-20 03:39:18 UTC
Some tools using OAuth generate a large number of edits. OAuth edits should be hide-able, or hidden by default, like bot edits.
Shouldn't these tools be using the bot flag if they're generating so many "uninteresting" edits?
(In reply to Brad Jorsch from comment #1) > Shouldn't these tools be using the bot flag if they're generating so many > "uninteresting" edits? Can one use the bot flag via API without having bot permission?
(In reply to Nemo from comment #2) > (In reply to Brad Jorsch from comment #1) > > Shouldn't these tools be using the bot flag if they're generating so many > > "uninteresting" edits? > > Can one use the bot flag via API without having bot permission? No, the bot flag is ignored even if set for users not in the bot group.
(In reply to Brad Jorsch from comment #1) > Shouldn't these tools be using the bot flag if they're generating so many > "uninteresting" edits? It's not the tool that's editing, it's the user, through the tool. One possibility would be to optionally mark some OAuth edits as bot; the tool should be able to control that, however, since single/small-scale edits should not be hidden in Recent Changes.
IMO this should be WONTFIXed. OAuth edits are not special; they can be problematic and should be treated with the status of the account being used. There has been large scale misuse of Widar tools on Wikidata, resulting in bot accounts being blocked and even de-flagged.
typical use is either long lists of similar edits.. eg adding human politician nationality to people that can be identified as members of a particular parliament. The creation of items identified by being in a specific category. Adding images and labels through Reasonator. The point of hiding them as a group is that you can distinguish them as a group and get a clear view on the true manual edits. The point is not like with bots that they should not be seen. By hiding them as a group you do not confuse bots with oAuth enabled edits. It would be good to toggle them to exclusive view, Thanks, GerardM
(In reply to John Mark Vandenberg from comment #5) > IMO this should be WONTFIXed. OAuth edits are not special The implementation proposals vary, but the bug summary doesn't ask anything special. It's already possible to filter RC by Widar: https://www.wikidata.org/w/index.php?namespace=&tagfilter=OAuth+CID%3A+68&translations=noaction&title=Special%3ARecentChanges One possible improvement (in core) is to allow negative filtering and multiple labels; doesn't sound impossible.
(In reply to Nemo from comment #7) > (In reply to John Mark Vandenberg from comment #5) > > IMO this should be WONTFIXed. OAuth edits are not special > > The implementation proposals vary, but the bug summary doesn't ask anything > special. The "hidden by default" part of this bug is central. http://tools.wmflabs.org/wikidata-todo/autolist2.php currently says "Note: This tool is currently throttled to one edit every 10 seconds, because it would otherwise flood Recent Changes on Wikidata. Help me get [bug 64829] resolved, so the throttling can be removed again!" However the ability to flood is a permission which should be managed by the wiki community, and 'OAuth' should respect that. 'OAuth' is not something that could be trusted in itself - it is not even a single tool - it is just a bridge for any number of tools with different strengths and weaknesses. The current set of 'filters' on the RC UI could be improved so that any user group (including a new 'flood' group) could be included/excluded from the RC view. That is probably bug 4664. > It's already possible to filter RC by Widar: > https://www.wikidata.org/w/index. > php?namespace=&tagfilter=OAuth+CID%3A+68&translations=noaction&title=Special% > 3ARecentChanges > One possible improvement (in core) is to allow negative filtering and > multiple labels; doesn't sound impossible. Agreed; that would be good, but that is a very roundabout way to fix the OP's 'problem'. A more flexible filter system might be considered as part of the bug 21383/bug 25909 UI improvement, as a simple drop down would be going in the 'wrong' direction. A more flexible filter system might instead use a textbox with funky autocomplete assisting the user write a 'query' like "-bot -oauth +sometag -othertag -myedits -user:blah". A funky query syntax like that could be stored as a single user pref, eliminating the need for an ever growing number of boolean user prefs for RC and Watchlist defaults, e.g. bug 27050/bug 7039 (should those be dup'd the other way?) and bug 22213. (Ill stop dreaming now)
Sorry John, it seems you do not understand the issues at all. oAuth authenticates, it makes it possible to edit from outside of Wikidata. oAuth will NEVER do anything but that. It does not flood, the external tools that make use of oAuth do. When items were created as part of the project to register deaths in 2014, there were only a few at a time anyway. The throttling you talk about has been build in the tools themselves and, they have nothing with oAuth to do. Thanks, GerardM
John, right. I commented on some of those bugs, we still need a bug on negative filtering I think? Doesn't need to be new syntax, could just be an "invert" checkbox as we already have for namespaces; after that I suspect people would ask multiselection. (In reply to Gerard Meijssen from comment #9) > oAuth > authenticates, it makes it possible to edit from outside of Wikidata. oAuth > will NEVER do anything but that. It does not flood, the external tools that > make use of oAuth do. It's what he just said :) : (from comment #8) > 'OAuth' is not something > that could be trusted in itself - it is not even a single tool - it is just > a bridge for any number of tools with different strengths and weaknesses.
Situation at hand: * We have several tools that use Oauth * Some of these tools do a large amount of edits * These edits flood recent changes * Some of the users using these tools have a bot flag * The botflag isn't used We just want to get the botflag working.
The bot flag works well. OAuth tools which flood RC should not work with accounts which do not have the bot flag. Then ppl will ask for the bot flag and be expected to follow the local bot policy.
There are two separate bug reports being conflated into one here. 1) If a user is flagged as a bot, then any edits they make via OAuth are not flagged as bot edits. 2) There should be a way to hide all OAuth edits from Special:RecentChanges. I've reported the former as bug 65494. The latter is more complex. Bot flags are account-level settings, so having some edits on an account flagged as bot edits (OAuth ones) and others not (normal ones) disrupts the model people have for how the bot flag works. I think explicit filtering on Special:RecentChanges (e.g. "Show/hide OAuth edits") would be the better option. The downside is extra clutter in the interface, but I'd rather it be a bit cluttered than really unclear.
(In reply to Maarten Dammers from comment #11) > * Some of the users using these tools have a bot flag > * The botflag isn't used The botflag isn't used because the tool doesn't include the appropriate parameter (e.g. bot=1 for action=edit)? Or because the grants for the tool don't include "High-volume editing"? Because OAuth does nothing to prevent the bot flag from working in exactly the same way that it does for edits made using traditional auth, assuming the account has the 'bot' right, the grants include the 'bot' right, and the actual request indicates that it should be flagged. I tend to agree with comment 12 here, although an enhanced tag filter might be useful if it's technically possible (i.e. if the resulting queries don't blow up the database).
(In reply to Brad Jorsch from comment #14) > (In reply to Maarten Dammers from comment #11) > > * Some of the users using these tools have a bot flag > > * The botflag isn't used > > The botflag isn't used because the tool doesn't include the appropriate > parameter (e.g. bot=1 for action=edit)? Or because the grants for the tool > don't include "High-volume editing"? Because OAuth does nothing to prevent > the bot flag from working in exactly the same way that it does for edits > made using traditional auth, assuming the account has the 'bot' right, the > grants include the 'bot' right, and the actual request indicates that it > should be flagged. Yeah, the problem is that it's really unclear how the bot flag actually works. As someone who's never used the API for anything serious, I was totally unaware that the API allows for edit-level granularity on bot edits, because there is no such granularity in the editing interface; ironically, any and all edits you make manually are tagged as bot edits. The above is actually a separate issue and has nothing to do with this bug, or even OAuth.
The botflag will be used by OAuth if the user editing through OAuth has a bot flag. I already removed the throttling for this specific case; some of us have bot-flagged user accounts for this purpose, and those high-frequency edits are neatly hidden away now AFAIK. That works, in a way. What I would /prefer/ is a way for the tool to say "these are high-frequency edits", which are hidden like bot edits, or for the tool to say "this is a singular edit", in which case the edit shows. That way, I wouldn't have to run two accounts on Wikidata, it's just silly.
Magnus, is https://bitbucket.org/magnusmanske/magnustools/src/ecb01ddc26c8129737d260d0491ccb410c4c62a3/public_html/php/oauth.php?at=master the code that is used for high frequency edits? That doesn't seem to set bot=1 so these edits will show up in recent changes. You should probably add a user option like "run fast". That should check if the user can set the botflag and if it's the case, run faster and set that on every edit. If that works well we can use start handing out flood flags to trusted users.
It's been editing as bot for some time; maybe I didn't commit it? Look for 'bot' => 1 on https://bitbucket.org/magnusmanske/magnustools/src/f829ccc00ca2c4ebff1ccd004b33d44fdc6c04e9/public_html/php/oauth.php?at=master
Can somebody summarize the current status here? I am rather interested in the throttle being removed from Magnus's AutoList 2 (without me having to hack it in the JS console every time).
I've been playing around with AutoList 2 (made several hundred edits on my personal account; fun!) So, I'm sympathetic to "moar, faster!" I think there's a policy question that someone (Magnus or whoever wants to drive this) needs to sort out with the Wikidata community about the preconditions for allowing AutoList to run faster on Wikidata.org specifically. That may result in a feature request (e.g. grouping items in recent changes by user), or it may not be necessary for a new feature. If the Wikidata community believes a new feature is needed, I would ask that Lydia Pintscher or Daniel Kinzler vet the feature request. It would appear, based on the conversation above, that Maarten Dammers suggests some integration of bot/flood permission querying, and going faster if the account has permissions. Magnus's response indicates he had some trouble implementing this. He's going to be the one to ask for status on that. Regardless, the request to generally allow hiding of oAuth edits seems like the wrong feature to me, and I'd suggest we close this one as "wontfix".
I think WONTFIX is best here, yes. We have the 'bot' flag for marking high-volume edits, and a tool using OAuth to make high-volume edits should be being used with accounts that have been approved by the relevant community to make high-volume edits. Bot flagging via the API works just as well when authenticated via OAuth as it does via normal auth (as long as use of the 'bot' flag was included in the OAuth grants), and querying for the bot flag can be done via both meta=userinfo and via the OAuth JWT identification ([[mw:Extension:OAuth#Identify the User (optional)]]).
