Last modified: 2010-05-15 15:54:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16241, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14241 - Pages can be protected to levels you aren't in
Pages can be protected to levels you aren't in
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page protection (Other open bugs)
1.12.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Ryan Schmidt
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-23 20:49 UTC by Shaiaqua
Modified: 2010-05-15 15:54 UTC (History)
3 users (show)

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


Attachments

Description Shaiaqua 2008-05-23 20:49:35 UTC
Pages can be protected to levels you aren't in (and then you can't unprotect), and can be deleted without having the edit right for that page.
Comment 1 Aaron Schulz 2008-05-23 20:51:13 UTC
Auh, can you give some examples of this, or how to do it?
Comment 2 Aaron Schulz 2008-05-23 20:53:08 UTC
As far as deletion goes, I don't see why they would need to be coupled.

They only way to protect to levels beyond yourself is with some strange custom configurations. I'm not even sure if that is necessarily *wrong* either.
Comment 3 Shaiaqua 2008-05-23 20:56:21 UTC
I added a right to the protection list, that's the only config change I made for this. 
It lets you protect the page, but then it stops you from unprotecting it. 
Comment 4 Ryan Schmidt 2008-05-23 21:13:14 UTC
I've noticed this too on my local wiki where I added in an additional level to $wgRestrictionLevels. You can protect past your level, but cannot subsequently unprotect the page. As for deletion, I agree with Aaron in not seeing why they would need to be coupled together.

Anyway, I'll take this bug since I made a working patch for this on 1.11.0 (and subsequently lost it when upgrading without keeping the diff file, but it shouldn't be hard to make it again for the latest trunk), so I already know what I'm doing.

I'm holding off on implementing the deletion aspect as that is a completely different topic and probably deserves its own bug unless comments below lead to a consensus that it should also be implemented.
Comment 5 Shaiaqua 2008-05-23 21:26:20 UTC
Alright, thanks.

Should I make the other bug report, or is it not really an issue?
Comment 6 Ryan Schmidt 2008-05-24 01:27:24 UTC
make the report if you think it should be a feature
Comment 7 Ryan Schmidt 2008-05-24 16:49:58 UTC
Fixed protection issue in r35285, changed bug summary to not include the deletion aspect, open up a new bug for that
Comment 8 Shaiaqua 2008-05-24 17:46:48 UTC
I replaced the old protectionform.php with the new one, and now &action=protect shows a blank page.
Comment 9 Roan Kattouw 2008-05-24 17:59:31 UTC
(In reply to comment #8)
> I replaced the old protectionform.php with the new one, and now &action=protect
> shows a blank page.
> 

Of course it does. ProtectionForm.php depends on lots of other files, you need to upgrade *all files*.
Comment 10 Shaiaqua 2008-05-24 18:05:54 UTC
That was the only file in the patch... Do I need to download the entire program from svn?

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


Navigation
Links