Last modified: 2011-01-25 01:24:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6579 - Allowing protecting files without protecting image pages
Allowing protecting files without protecting image pages
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Normal enhancement with 14 votes (vote)
: ---
Assigned To: Bryan Tong Minh
:
: 17037 22316 (view as bug list)
Depends on:
Blocks: 22521
  Show dependency treegraph
 
Reported: 2006-07-07 12:46 UTC by とある白い猫
Modified: 2011-01-25 01:24 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Proposed patch (2.71 KB, patch)
2009-10-27 15:25 UTC, Bryan Tong Minh
Details

Description とある白い猫 2006-07-07 12:46:04 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.
Comment 1 Daniel Arnold 2006-07-07 12:56:22 UTC
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.
Comment 2 Joe Anderson 2006-07-07 16:15:24 UTC
(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
Comment 3 とある白い猫 2006-07-07 16:24:18 UTC
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.
Comment 4 とある白い猫 2007-05-28 13:22:14 UTC
The summary can change (such as stuff like recategorization and etc)
Comment 5 Brion Vibber 2007-05-30 19:29:52 UTC
I don't see any reason for this.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-30 21:42:56 UTC
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.?
Comment 7 とある白い猫 2007-06-01 21:12:40 UTC
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.
Comment 8 Aaron Schulz 2007-06-01 21:20:51 UTC
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.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-01 21:24:12 UTC
(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.
Comment 10 Aaron Schulz 2007-06-01 21:25:41 UTC
heh, and the "Unlock move permissions" does look kind of funky :)
Comment 11 Bryan Tong Minh 2008-04-28 17:52:23 UTC
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.


Comment 12 Bryan Tong Minh 2008-10-05 20:44:59 UTC
(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.
Comment 13 Lejonel 2009-03-10 16:30:28 UTC
*** Bug 17037 has been marked as a duplicate of this bug. ***
Comment 14 Bryan Tong Minh 2009-10-27 15:25:10 UTC
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.
Comment 15 Bryan Tong Minh 2009-11-04 12:55:41 UTC
Fixed in r58537 
Comment 16 The Evil IP address 2009-11-25 21:36:36 UTC
(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]]
Comment 17 Jake Wartenberg 2009-12-08 03:52:46 UTC
This is gone now, on enwiki at least.  Can anyone tell us what has happened?
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-12-08 17:56:56 UTC
The bug has been fixed in trunk as of r58537, but is probably not yet live on Wikimedia sites.
Comment 19 Jake Wartenberg 2009-12-08 22:33:59 UTC
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.
Comment 20 Roan Kattouw 2009-12-08 23:28:30 UTC
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.
Comment 21 Bryan Tong Minh 2009-12-09 14:18:58 UTC
It has been disabled in r59419, but will probably be back when some related core changes have been merged in.
Comment 22 MZMcBride 2009-12-09 14:21:52 UTC
(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.

Comment 23 Alex Z. 2010-02-13 00:46:35 UTC
Am I missing something? r59419 only disabled it in wmf-deployment. I believe this works on trunk.
Comment 24 Happy-melon 2010-02-14 19:37:39 UTC
Confirmed FIXED on trunk.  Please continue to chew your fingernails patiently.  :-D
Comment 25 Casey Brown 2010-04-16 01:42:28 UTC
*** Bug 22316 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links