Wikimedia Bugzilla is closed!

Created attachment 8638 [details]
screenshot of firebug before modification took place

Created attachment 8639 [details]
screenshot of firebug @ modification time

Created attachment 8640 [details]
screenshot of firebug after modification took place

Created attachment 8641 [details]
Common's configuration

(In reply to comment #0)
> Created attachment 8637 [details]
> A few comments on mw.UploadWizardLicenseInput.js
>
Instead of re-submitting the entire file, please submit a patch file instead.

Sorry for being not a professional developer. I was not involved in the development of upload wizard and simply wanted to submit a bug. I am not familiar with the deep structure of it.

But I suggest replacing l. 61 which currently is
var templates = mw.isDefined( license.props['templates'] ) ? license.props.templates : [ license.name ];

with

var templates = mw.isDefined( license.props['templates'] ) ? $j.extend(true, {}, license.props.templates) : [ license.name ];

or something similar. I don't know the installation of jQuery and so on ... It is your turn to find out whether this would work.

Sincerely Rillke

Rainer: I don't know what problem you are trying to solve here and don't have the time to figure it out. Please explain it in words.

(In reply to comment #6)
>  It
> is your turn to find out whether this would work.

I appreciate your enthusiasm but are you *sure* you can't figure out if your patch works or not? I would happily commit a well-tested patch.

Otherwise this goes to the bottom of my "things to do" pile.

Marking as enhancement unless / until this patch is shown to fix an existing bug, or explained in some way.

The problem is that when an image is uploaded using UploadWizard on commons that is licensed with {{PD-USGov}}, then it seems that automaticly a {{flickrreview}} is attached, while there is not the slightest relation to flickr. Here is an example: http://commons.wikimedia.org/w/index.php?title=File:Bellamy_House_Wilmington_North_Carolina_by_Frances_Benjamin_Johnston.jpg&oldid=55506689.

Created attachment 8677 [details]
requested bugfix

The change of the bug-title was wrong. This is only the symptom.

I now submit a fix that should work. 

Again: The script changed the media-wiki-config, set with (mediaWiki.config.set({"UploadWizardConfig": {) (see previous attachment). This is now prevented by cloning the array. Don't presume I am talking about ghosts again. That's something I really dislike. If you would have taken the time to read my comments in the "resubmitted source-file", you would know what I am talking about. Grrrrr ;-)

With best regards Rainer Rillke (RE)

(In reply to comment #9)
> Marking as enhancement unless / until this patch is shown to fix an existing
> bug, or explained in some way.
Neil, this looks legit to me. Apparently some config var is assigned to another var somewhere and manipulated later, but because of the by-reference nature of array assignments in JS, this ends up manipulating the config itself, which is kind of evil and apparently leads to pollution. The proposed fix (there's no patch but see comment #6) is to clone the array with something like var bar = $.extend( {}, foo ); instead of var bar = foo;

> there's no patch but see comment #6
Now, there is a patch, feel free to remove the comments in ll. 59, 61, 65
> $.extend( {}, foo );
Please do not use this. Instead use $.extend( [], foo ); Otherwise it is not an array, only an object (without length property and join-function, ...)
But you can just use my proposed fix in comment #11

Thanks for working on this subject. Sincerely Rillke

(In reply to comment #13)
> > there's no patch but see comment #6
> Now, there is a patch, feel free to remove the comments in ll. 59, 61, 65
By 'patch' I meant a patch file in unified diff format, listing the changes between our version and yours.

> > $.extend( {}, foo );
> Please do not use this. Instead use $.extend( [], foo ); Otherwise it is not an
> array, only an object (without length property and join-function, ...)
> But you can just use my proposed fix in comment #11
>
Yes, [] instead of {}, my bad.

> unified diff format
 --> is this something I can do?

Help says: "If the patch is not in a format that you like, you can turn it into a unified diff format by clicking the "Raw Unified" link at the top of the page."

Should I have submitted the original file first and then the changes? (Sorry I'm new to bugzilla.)

Is there another way to speed-up fixing?

(In reply to comment #15)
> > unified diff format
>  --> is this something I can do?
> 
> Help says: "If the patch is not in a format that you like, you can turn it into
> a unified diff format by clicking the "Raw Unified" link at the top of the
> page."
> 
> Should I have submitted the original file first and then the changes? (Sorry
> I'm new to bugzilla.)
> 
I have no idea how that works. I just make my patches on the command line.

> Is there another way to speed-up fixing?
It's a one-line fix so this is fine. For now you'll just have to wait until Monday or later for Neil to see this and have time for this.

And now we have a new Bug 29994 . With some additions. 

But the license templates are just a configuration issue. You just have to change licensesThirdParty of comment #4 from "and" to "or" . That's all.

Created attachment 8855 [details]
patch in unified diff - format as requested

This patch should resolve the following symptoms:
* Inaccurately adding License-Review templates if user selected PD-US-Gov
* Prevent Template-Loop like {{self|self|self|cc-0}}

This is done by cloning the object instead of passing a reference.

Q: Why do you use a deep-copy?
A: We do not know what follows in future so a deep copy is much saver.

WARNING: There is no warranty of merchantability nor of fitness for a particular purpose.

This could also be fixed by integrating the mw.FlickrChecker.js functionality into UploadWizard, so that Flickr licenses are handled automatically. The code that interfaces with Flickr is already written, but I never actually integrated it into UW.

Is this still an issue? I can't reproduce it locally on trunk; if I check "Original work of the US Federal Government", I only get a {{PD-USGov}}, not a flickr-review tag.

... I can however reproduce it on Commons, doing the same thing: http://commons.wikimedia.org/wiki/File:Test_file_for_bug_29346.png

The author of the bug report wanted to fix multiple issues. The one that's more of a policy change was split off into #29994, which is good.

The rest is the same underlying issue as #30237, which I just fixed. In retrospect, now I understand what Rainier was talking about.

*** This bug has been marked as a duplicate of bug 30237 ***

Is it common practise to mark older bugs as dupes of newer ones, Neil?

(In reply to comment #22)
> Is it common practise to mark older bugs as dupes of newer ones, Neil?

I am from the future.

Sorry, I am not (from the future). And someone seem to forgot to deploy this to MW1.18. Ouch! Just try upload wizard on commons. It produces the same mistakes again:
*self-loop: 
1) upload multiple files and "select the license for each file in the next step", then select cc0
2) cancel the upload declaring it is not your own work and then selecting a file and uploading this
* flickrreview:
1) at us-gov-source not from flickr

Someone from the past could be upset now. ;-)

Rainer: I feel your pain. After we deployed I saw that again and was hoping it was some kind of optical illusion.

We are deploying again Monday, hopefully. This time I will rebranch from trunk which ought to cure all regressions.

(In reply to comment #25)
> We are deploying again Monday, hopefully. This time I will rebranch from trunk
> which ought to cure all regressions.

Did it?

Please close this bug if they are cured.

after the deploy on 2011-10-26 this should be fixed again. Tested and cannot make it happen.