Last modified: 2011-11-22 00:21:03 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 T17821, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15821 - Allow specific users to edit otherwise blocked articles
Allow specific users to edit otherwise blocked articles
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.14.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 14636
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-03 23:03 UTC by Platonides
Modified: 2011-11-22 00:21 UTC (History)
10 users (show)

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


Attachments

Description Platonides 2008-10-03 23:03:16 UTC
This is the inverse of bug 674.
Sometimes there are some valuable, trustable, contributors (templates, javascript, legal...) for which it would be useful to allow editing some fully protected pages.

The needed fields are pretty much the same as user_restrictions and IMHO the same table should be used for both, which also mean just one schema change.

The fetch for per-user restrictions would be done before and added to the "if( '' != $right && !$user->isAllowed( $right ) )"  if it was of type protectededit, and on the place on which it was done if of type restrictedit.
I feel tempting to also add more fine-grained types (like separate moving or fixing bug 4995) but perhaps it's moving it too much for per-user rights?
Comment 1 KnightLago 2008-10-04 01:10:30 UTC
Has there been any community discussion about this? Is there really a need? Valuable, trustable, contributors sound a lot like administrators.  
Comment 2 Platonides 2008-10-04 14:13:15 UTC
(In reply to comment #1)
> Valuable, trustable, contributors sound a lot like administrators.  

Being an administrator also carries other 'duties'.
It isn't to requere a user which decided to stop being an admin in order to focus in article-writing to pass an RfA again only for editprotected.
Plus, there are cases where they may be trusted to edit, but not for deleting or blocking (eg. he has problems staying calm).

Another use case are users whose user page has to be protected. With this system they can be given the extra permission to edit their userpage.
Comment 3 Gurch 2008-10-06 22:26:19 UTC
If you want users who can be trusted to edit protected pages to be able to edit protected pages, grant them administrator access. Your problem is with the English Wikipedia's request process for administrator access. Asking for a workaround in MediaWiki is taking completely the wrong approach to the problem. Fix the process instead.
Comment 4 MZMcBride 2008-10-06 22:32:52 UTC
The all-or-none approach with regard to +sysop isn't anywhere near ideal from a social or pragmatic perspective.

Currently the only real way to have non-admins edit protected pages would be to create a separate user group with the 'editprotected' right. This has a number of disadvantages and is far less customizable than what this bug requests.

Customization for non-WMF projects is a goal of the MediaWiki software. Whether this would be a good thing for Wikimedia wikis remains to be discussed (on mailing lists, Meta, etc.), but I see no reason to WONTFIX this at the moment (at least not while bug 674 remains open). And, obviously, there is always the possibility of including this feature in the core software while leaving it disabled for Wikimedia.

Reopening the bug.
Comment 5 Gurch 2008-10-06 22:41:47 UTC
@MZMcBride: Yes, letting non-admins edit protected pages would be tricky. That's a good thing; why would the potentially most damaging thing an administrator can do be assigned to users without the other permissions? I repeat, the problem here is entirely with the English Wikipedia's request process for administrator access. Plaitonides sums it up well. You are proposing an engineering fix for a social problem. Such a thing *never* works.

If a non-Wikimedia projects asked for this, it would be a different matter, but none has, or is likely to, having as they generally do far saner processes for giving out administrator access.
Comment 6 MZMcBride 2008-10-06 22:52:28 UTC
The use-case for User: pages that have to be fully protected from editing due to ongoing vandalism is enough to warrant this feature, in my mind.

Another use-case would be people who are skilled in specific areas like JS or CSS who could have access to Common.js or Common.css without needing the admin bit, which has a variety of other permissions that they would not need (e.g., block, delete). Users who are well-versed in JavaScript or CSS are not necessarily well-versed in other aspects of a wiki (when to block, protect, etc.).

There are likely a number of other use-cases for this feature. With thousands of MediaWiki installations, it's undoubtedly true that someone has requested this feature or would benefit from the addition of it. And so it's filed under "MediaWiki," not "Wikimedia." ;-)
Comment 7 Andrew Garrett 2008-10-06 23:53:56 UTC
I agree that this has at least some utility. I don't agree with the proposed implementation strategy. We need to have a unified approach to access control, rather than just tacking on extra hacks when we need them. At least some portion of the access control system needs a rewrite.
Comment 8 Gurch 2008-10-07 15:26:35 UTC
@MZMcBride: There are no User: pages that *have* to be fully protected, just overzealous adminstrators/protection requests. Semi-protection is good enough for [[Wikipedia]], [[Wiki]] and [[George W. Bush]], no userpage gets even a tenth of the attention that those do.
Comment 9 Bugmeister Bot 2011-08-19 19:13:00 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

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


Navigation
Links