Last modified: 2011-03-13 18:05:16 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 2352 - New feature to automatically protect user: page
New feature to automatically protect user: page
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.5.x
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-08 14:32 UTC by cd powers
Modified: 2011-03-13 18:05 UTC (History)
0 users

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


Attachments

Description cd powers 2005-06-08 14:32:25 UTC
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
Comment 1 lɛʁi לערי ריינהארט 2005-06-08 16:47:36 UTC
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
Comment 2 cd powers 2005-06-08 18:23:37 UTC
(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
Comment 3 Michael Keppler 2005-06-08 18:34:41 UTC
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.
Comment 4 cd powers 2005-06-08 19:50:17 UTC
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
Comment 5 lɛʁi לערי ריינהארט 2005-06-09 08:11:09 UTC
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
Comment 6 Michael Keppler 2005-06-10 17:43:24 UTC
(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.

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


Navigation
Links