Allow specific users to edit otherwise blocked articles
Open, MediumPublicFeature
Actions

Assigned To

None

Authored By

	Platonides
	Oct 3 2008, 11:03 PM

Description

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?

Version: 1.14.x
Severity: enhancement

Details

Reference: bz15821

Related Objects
Search...

Status	Subtype	Assigned	Task
Open	Feature	None	T17821 Allow specific users to edit otherwise blocked articles
Duplicate		None	T16636 Blocking/Permissions Rewrite
Resolved		None	T18644 Allow users to be blocked from editing non-talk pages only
Resolved		DannyS712	T20807 Phase out right-related globals
Resolved		DannyS712	T232169 Deprecate `wgSysopEmailBans`
Resolved		DannyS712	T233116 Remove `$wgSysopEmailBans`, deprecated in 1.34
Open		None	T18447 Software should allow blocks that only expire when a user has read a specified page (training module, user talk page, etc.)

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:21 PM

• bzimport added a project: MediaWiki-Page-editing.

• bzimport set Reference to bz15821.

• bzimport added a subscriber: Unknown Object (MLST).

Platonides created this task.Oct 3 2008, 11:03 PM

KnightLago wrote:

Has there been any community discussion about this? Is there really a need? Valuable, trustable, contributors sound a lot like administrators.

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

matthew.britton wrote:

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.

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.

matthew.britton wrote:

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

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." ;-)

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.

matthew.britton wrote:

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