Last modified: 2014-11-20 03:39:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T66829, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 64829 - Allow hiding OAuth edits in Recent Changes
Allow hiding OAuth edits in Recent Changes
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
OAuth (Other open bugs)
unspecified
All All
: Normal enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-05-04 15:13 UTC by Magnus Manske
Modified: 2014-11-20 03:39 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Magnus Manske 2014-05-04 15:13:15 UTC
Some tools using OAuth generate a large number of edits. OAuth edits should be hide-able, or hidden by default, like bot edits.
Comment 1 Brad Jorsch 2014-05-05 14:04:03 UTC
Shouldn't these tools be using the bot flag if they're generating so many "uninteresting" edits?
Comment 2 Nemo 2014-05-05 17:28:49 UTC
(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?
Comment 3 Magnus Manske 2014-05-05 18:17:05 UTC
(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.
Comment 4 Magnus Manske 2014-05-05 18:19:19 UTC
(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.
Comment 5 John Mark Vandenberg 2014-05-16 23:34:22 UTC
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.
Comment 6 Gerard Meijssen 2014-05-17 05:10:27 UTC
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
Comment 7 Nemo 2014-05-17 06:52:12 UTC
(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.
Comment 8 John Mark Vandenberg 2014-05-19 11:24:07 UTC
(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)
Comment 9 Gerard Meijssen 2014-05-19 11:34:41 UTC
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
Comment 10 Nemo 2014-05-19 13:08:54 UTC
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.
Comment 11 Maarten Dammers 2014-05-19 14:16:28 UTC
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.
Comment 12 John Mark Vandenberg 2014-05-19 14:42:45 UTC
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.
Comment 13 Dan Garry 2014-05-19 17:18:52 UTC
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.
Comment 14 Brad Jorsch 2014-05-19 17:53:46 UTC
(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).
Comment 15 Dan Garry 2014-05-19 22:02:45 UTC
(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.
Comment 16 Magnus Manske 2014-05-20 14:40:18 UTC
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.
Comment 17 Maarten Dammers 2014-05-20 16:54:06 UTC
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.
Comment 18 Magnus Manske 2014-07-23 20:07:21 UTC
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
Comment 19 Bartosz Dziewoński 2014-08-14 12:21:51 UTC
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).
Comment 20 Rob Lanphier 2014-11-17 07:18:33 UTC
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".
Comment 21 Brad Jorsch 2014-11-17 15:02:08 UTC
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)]]).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links