arnomane wrote:

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.

computerjoe wrote:

(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.

ayg wrote:

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.

ayg wrote:

(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 :)

Bryan.TongMinh wrote:

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.

Bryan.TongMinh wrote:

(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. ***

Bryan.TongMinh wrote:

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.

Attached:

Bryan.TongMinh wrote:

Fixed in r58537

TheEvilIPaddress wrote:

(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]]

jake wrote:

This is gone now, on enwiki at least. Can anyone tell us what has happened?

ayg wrote:

The bug has been fixed in trunk as of r58537, but is probably not yet live on Wikimedia sites.

jake wrote:

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.

Bryan.TongMinh wrote:

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.

happy.melon.wiki wrote:

Confirmed FIXED on trunk. Please continue to chew your fingernails patiently. :-D

bugs wrote:

*** Bug 22316 has been marked as a duplicate of this bug. ***