Last modified: 2011-01-25 01:24:26 UTC
It would be of great help if we were able to protect images and not their summaries, especialy in commons where many images will unlikely change.
This separate protection ability would help for example with images being presented on main pages of Wikimedia wikis and the Wikimedia logos hosted in Commons. That way we can avoid locking down Wikimedia Commons in many places and could still edit the meta information (description, category, license tag...) of that images.
(In reply to comment #1) > This separate protection ability would help for example with images being presented on main pages > of Wikimedia wikis and the Wikimedia logos hosted in Commons. That way we can avoid locking down > Wikimedia Commons in many places and could still edit the meta information (description, > category, license tag...) of that images. You are correct, though I'm sure lots of commonly viewed pages are mainly comprised of fair use images. These can't be placed on WMC
Negative. Images on de.wiki for instance are never fair use as de.wiki does not allow fair-use. Fair-use images can be protected in local wiki. This thing just allows protection of the image and not the summary for images that are unlikely to change.
The summary can change (such as stuff like recategorization and etc)
I don't see any reason for this.
Um . . . you don't think that the concept of protecting [[Image:Wiki.png]] from being changed to a penis is distinct from protecting its description page so that people can't update the copyright templates, add localized descriptions (on Commons/Meta/...), etc.?
This is a really necessary feature we need especially on commons. It is particularly useful to have this ability to protect good images (the binary data of the image itself) that are unlikely to change. The image page (the wiki page) will however need frequent updating such as addition of localized descriptions or categorization.
I suppose I could make an 'upload' pr_type. One issue is that the protection form is not as dynamic as it could be, adding a third set (uploads) for images looks kind of funky.
(In reply to comment #8) > One issue is that the protection > form is not as dynamic as it could be, adding a third set (uploads) for images > looks kind of funky. amidaniel is already looking at adding a third set of controls for spidering control. A fourth should be less of an issue, if it's done properly.
heh, and the "Unlock move permissions" does look kind of funky :)
I updated the backend to honor upload protection on upload and revert. I did however not change the frontend yet. In principle $wgRestrictionTypes[] = 'upload' could be set, but there are a couple of issues: * "Unlock move permissions" does look a kind of funky as per comment #10 * The upload protection box appears on all namespaces * There is no "cascading upload protection". This feature would allow protection of all images on a page. Of course, if this were implemented the upload protection box on other namespaces would perfecly make sense.
(In reply to comment #11) > * "Unlock move permissions" does look a kind of funky as per comment #10 They look less funky now, but still require their own checkbox.
*** Bug 17037 has been marked as a duplicate of this bug. ***
Created attachment 6725 [details] Proposed patch Patch: * Upload protection box is only shown for files * Checkbox moved out of the move-fieldset and message changed to "Unlock further permissions" I'm not entirely convinced that it looks nice, so I did not commit it yet.
Fixed in r58537
(In reply to comment #15) > Fixed in r58537 > I thank you a lot for fixing this. This is making things on Commons a lot easier. --[[commons:User:The Evil IP address]]
This is gone now, on enwiki at least. Can anyone tell us what has happened?
The bug has been fixed in trunk as of r58537, but is probably not yet live on Wikimedia sites.
I am not sure you understand. We got this feature on enwiki, had it for a few days, and lost it. Enwiki is currently at r59476.
Enwiki is at r59476 of the wmf-deployment branch, which roughly corresponds to r56150 of trunk. r58537 from trunk has not been merged in yet. Reclosing.
It has been disabled in r59419, but will probably be back when some related core changes have been merged in.
(In reply to comment #21) > It has been disabled in r59419, but will probably be back when some related > core changes have been merged in. Re-opening this bug accordingly.
Am I missing something? r59419 only disabled it in wmf-deployment. I believe this works on trunk.
Confirmed FIXED on trunk. Please continue to chew your fingernails patiently. :-D
*** Bug 22316 has been marked as a duplicate of this bug. ***
