This is a blocker for deployment to the Commons.
The flickr uploader *must* honor the community-maintained user blacklist at
https://commons.wikimedia.org/wiki/User:FlickreviewR/bad-authors
Otherwise we get far too many flickr-washed files.
The location of the blacklist must be configurable on-wiki.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T45450 UploadWizard Flickr (tracking) | |||
| Resolved | Tgr | T44307 Implement a way for admins to blacklist Flickr users |
(In reply to comment #0)
The location of the blacklist must be configurable on-wiki.
How exactly? As far as I know you can't add a message for configuration any more and creating a whole new special page for this seems like overkill.
(In reply to comment #1)
(In reply to comment #0)
The location of the blacklist must be configurable on-wiki.
How exactly? As far as I know you can't add a message for configuration any
more and creating a whole new special page for this seems like overkill.
"How exactly?" -- not my problem. But I presume if UW is ever to be used on other wikis, one cannot hard-code that blacklist location; and having it in the site-wide config is a very inconvenient approach.
Why can't one use a MediaWiki message for this, which would contain the name of the on-wiki page containing this blacklist?
Sample flickr URL of an image of a currently blacklisted user:
http://www.flickr.com/photos/endtohell/2194960865/
(No, I don't know off-hand why this user was blacklisted.)
(In reply to comment #2)
But I presume if UW is ever to be used on
other wikis, one cannot hard-code that blacklist location; and having it in the
site-wide config is a very inconvenient approach.
You are correct, if this blacklisting feature is implemented it must not be hardcoded to Wikimedia Commons.
Why can't one use a MediaWiki message for this, which would contain the name of
the on-wiki page containing this blacklist?
Configuration-by-message is a bad thing and to be discouraged.
(In reply to comment #4)
(In reply to comment #2)
Why can't one use a MediaWiki message for this, which would contain the name of
the on-wiki page containing this blacklist?Configuration-by-message is a bad thing and to be discouraged.
Why?
I strongly disagree with the classification of this bug as a mere "enhancement". Trust me, I know the Commons, and as the author of Flinfo, I know that the blacklisting ability is *crucial* for acceptance of this whole thing at the Commons.
Without blacklisting ability, this will fall through. (Rightly so, I think. Flickrwashing is a perennial problem, and some blacklisting mechanism is the only way Commons can currently fight it.)
Whether a blacklist is the best mechanism is open to discussion; if you can come up with some more clever scheme that also works, all the better. If a blacklist is used, where it is located is also not that important, but in any case the blacklist must be (a) available for Commons admins to modify, and (b) accessible by external tools.
I think we will need an API to find if a user is blacklisted, not sure how to store/make this list
(In reply to comment #6)
I strongly disagree with the classification as a mere "enhancement".
New functionality is by definition severity = "enhancement", no matter how important it is or not. You can express priority by the priority field.
Which field is the severity and which the priority, though? And if an enhancement is a blocker, which wording would be more likely to bring in needed eyes, or would either?
And does saving a comment save other fiddling with this thing?
(In reply to comment #10)
Which field is the severity and which the priority, though?
First is priority, second is severity. The UI is really bad, yeah. :(
And if an enhancement is a blocker, which wording would be more likely
to bring in needed eyes, or would either?
Good arguments, CC'ing people, setting an appropriate priority, maybe voting.
And does saving a comment save other fiddling with this thing?
Yes, it saves ALL changes.
A config parameter can be set which points to the page where such a list exists.. It will be the responsibility of the admins to protect this page. Flickr can blacklist a user by just matching with this page, but this has to be done on the client side using an AJAX call.
Is this proposal fine?
(In reply to comment #13)
Fix attempt for single photo uploads only
https://gerrit.wikimedia.org/r/#/c/42770/
This tries to only validate users on client-side, a check on the server side need to be implemented too. I guess this has to be done in the APIUpload with support from UploadWizard by a hook maybe?
Was waiting on this for some consensus and advice. That didn't come in much amount so I am trying to rework on this myself again.
Related URL: https://gerrit.wikimedia.org/r/65109 (Gerrit Change I97f8be973e942a732b9873c3b05f2e7790940503)
Nischay: Patch got merged - can this bug report be closed as RESOLVED FIXED or is more work required?
I think this will need some more work, maybe in the TitleBlacklist extension or UW where the hook I created should be used.
I am not working on this currently so resetting assignee.
Change 42770 had a related patch set uploaded by Gergő Tisza:
A way to blacklist flickr users.
Should be done. Accepts usernames (the ones in the URL - Flickr calls them path_alias) as well. You can use # at the beginning of the line for comments.
(In reply to comment #0)
The location of the blacklist must be configurable on-wiki.
It is now configurable per-wiki, but not on-wiki. (That seemed pointless - how often does the location of the blacklist change?)
Change 108167 had a related patch set uploaded by Gergő Tisza:
Make UploadWizard respect the Flickr blacklist on Commons
Also includes a new API - search for flickrblacklist at https://commons.wikimedia.beta.wmflabs.org/w/api.php
Change 108167 merged by jenkins-bot:
Make UploadWizard respect the Flickr blacklist on Commons
All patches merged a while ago - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?