Allowing protecting files without protecting image pages
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: enhancement

bzimport set Reference to bz6579.
ToAruShiroiNeko created this task.Via LegacyJul 7 2006, 12:46 PM
bzimport added a comment.Via ConduitJul 7 2006, 12:56 PM

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.

bzimport added a comment.Via ConduitJul 7 2006, 4:15 PM

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

ToAruShiroiNeko added a comment.Via ConduitJul 7 2006, 4:24 PM

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.

ToAruShiroiNeko added a comment.Via ConduitMay 28 2007, 1:22 PM

The summary can change (such as stuff like recategorization and etc)

brion added a comment.Via ConduitMay 30 2007, 7:29 PM

I don't see any reason for this.

bzimport added a comment.Via ConduitMay 30 2007, 9:42 PM

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

ToAruShiroiNeko added a comment.Via ConduitJun 1 2007, 9:12 PM

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.

aaron added a comment.Via ConduitJun 1 2007, 9:20 PM

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.

bzimport added a comment.Via ConduitJun 1 2007, 9:24 PM

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.

aaron added a comment.Via ConduitJun 1 2007, 9:25 PM

heh, and the "Unlock move permissions" does look kind of funky :)

bzimport added a comment.Via ConduitApr 28 2008, 5:52 PM

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.
bzimport added a comment.Via ConduitOct 5 2008, 8:44 PM

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.

Lejonel added a comment.Via ConduitMar 10 2009, 4:30 PM

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

bzimport added a comment.Via ConduitOct 27 2009, 3:25 PM

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: patch.txt

bzimport added a comment.Via ConduitNov 4 2009, 12:55 PM

Bryan.TongMinh wrote:

Fixed in r58537

bzimport added a comment.Via ConduitNov 25 2009, 9:36 PM

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

bzimport added a comment.Via ConduitDec 8 2009, 3:52 AM

jake wrote:

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

bzimport added a comment.Via ConduitDec 8 2009, 5:56 PM

ayg wrote:

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

bzimport added a comment.Via ConduitDec 8 2009, 10:33 PM

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.

Catrope added a comment.Via ConduitDec 8 2009, 11:28 PM

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.

bzimport added a comment.Via ConduitDec 9 2009, 2:18 PM

Bryan.TongMinh wrote:

It has been disabled in r59419, but will probably be back when some related core changes have been merged in.

MZMcBride added a comment.Via ConduitDec 9 2009, 2:21 PM

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

Mr.Z-man added a comment.Via ConduitFeb 13 2010, 12:46 AM

Am I missing something? r59419 only disabled it in wmf-deployment. I believe this works on trunk.

bzimport added a comment.Via ConduitFeb 14 2010, 7:37 PM

happy.melon.wiki wrote:

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

bzimport added a comment.Via ConduitApr 16 2010, 1:42 AM

bugs wrote:

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

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:43 AM
Gilles moved this task to Closed on the Multimedia workboard.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.