Page MenuHomePhabricator

New feature to automatically protect user: page
Closed, DeclinedPublic

Description

Author: cdpowers

Description:
Maybe this is a new feature request, but here goes:

Rule: Protect User: pages from editing from everyone except sysops and
registered user that "owns" user: page


Version: 1.5.x
Severity: enhancement

Details

Reference
bz2352

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:32 PM
bzimport set Reference to bz2352.
bzimport added a subscriber: Unknown Object (MLST).

gangleri wrote:

Halló!

If a feature like this would be implemented then it probably should provide some
flexibility:
Users should be able to protect / unprotect own pages as [[User:foo]] but
probably not [[User talk:foo]].
Question: What should be the *default* value *unprotected* as it was until now
or *protected*?

Questions arive what should happen to subpages?
[[User:foo/bar]] might be handled the same way but probably not [[User
talk:foo/bar]].

Skin pages have a special treatment already (they are protected):
[[User:foo/Monobook.css]], [[User:foo/Monobook.js]] etc. Maybe also Java
subpages. How should the enhancement handle these.

Regards Reinhardt

cdpowers wrote:

(In reply to comment #1)

Halló!

If a feature like this would be implemented then it probably should provide some
flexibility:
Users should be able to protect / unprotect own pages as [[User:foo]] but
probably not [[User talk:foo]].
Question: What should be the *default* value *unprotected* as it was until now
or *protected*?

Questions arive what should happen to subpages?
[[User:foo/bar]] might be handled the same way but probably not [[User
talk:foo/bar]].

Skin pages have a special treatment already (they are protected):
[[User:foo/Monobook.css]], [[User:foo/Monobook.js]] etc. Maybe also Java
subpages. How should the enhancement handle these.

Regards Reinhardt

Thanks, Reinhardt. I appreciate the chance to collaborate.

I agree with all your points about flexibility. Allow users to turn off/on
protection of user pages. I suggest the default value should be protection on.
I also agree with your assesment of user talk pages and sub pages. No changes
necessary there.

I am not familiar with your comments regarding Java subpages, etc. Hopefully,
the intent of this suggestion will lead to a clear path for any extension of
this enhancement.

Thx

Cd

Michael.Keppler wrote:

I've implemented this protection (without any options) for my wiki by adding the
following to includes\Title.php, function userCan($action):

		if( NS_USER == $this->mNamespace
			&& $wgUser->getName() != $this->mTextform 
			&&

(substr_compare($wgUser->getName().'/',$this->mTextform,0,strlen($wgUser->getName())+1)
!= 0)

			&& !$wgUser->isAllowed( 'sysop' )) {
			wfProfileOut( $fname );
			return false;
		}

The code is similar to the protection for user skin and user JavaScript.

cdpowers wrote:

Mr. Keppler,

I successfully added the code you supplied to my wiki. With some modification.
And after a brief test, I believe it to be working satisfactorily. However, I
did have to comment out the second conditional statement because of syntactic
error otherwise. Could you explain that condition in a little more detail?
What do you think the consequences are of not referencing the second condition
in terms of the intent of the enhancment?

In any case, I still propose that Mediawiki provide users the capability to turn
on/off page protection of their individual user pages.

Thanks

cp

gangleri wrote:

slight difference
without the option for the user to protect / unprotect the *own* user page the
requested *feature* would be a *change* not a simple *enhancement*

Many (wikimedia foundation) wiki's have thousends of registered users where the
last contribution is several months ago. Sometimes I wonder if some of these
accounts have been created with bots ...

From the view pont *enhancement* versus *change* the "default value" should be
"unprotected".

Anyhow protect / unprotect the *own* user page implays a new context related tag
(namespace user and "own user page") and probbably a new action "protect own
user page" and optional implamentation in [[Special:Groups]] if it would not be
"hardcoded".

Regards Reinhardt

Michael.Keppler wrote:

(In reply to comment #4)

However, I
did have to comment out the second conditional statement because of syntactic
error otherwise.

I guess you use php 4.x? That doesn't yet have the substr_compare function.

Could you explain that condition in a little more detail?
What do you think the consequences are of not referencing the second condition
in terms of the intent of the enhancment?

The second statement is for sub pages of user pages. That statement looks for
page titles of the form "Username/somesubpagename" (it actually only looks for
the beginning including the slash). So if you don't have sub pages enabled for
the user name space, you will not even notice this missing statement. :)

Ciao, Michael.