Created attachment 836
patch

attachment CVS-REL1_5.diff ignored as obsolete

First, note that this provides no actual privacy protection. Contributions continue to
be listed in numerous places, including complete lists in page history. It would be
straightforward to scrape a user's complete contributions list should one want it.

Second, this isn't a very good switch as it's special-cased. Better would be to add a
permission key for each of these, and have it on the * group in the default
configuration. This would be more flexible, allowing any configuration (not just
sysops, but perhaps all logged-in users, or another special class).

(In reply to comment #2)

First, note that this provides no actual privacy protection. Contributions

continue to

be listed in numerous places, including complete lists in page history. It

would be

straightforward to scrape a user's complete contributions list should one want it.

Agreed. Intention was to disallow (e.g.) directors (easily) browsing the
contributions of their staff.

Second, this isn't a very good switch as it's special-cased. Better would be

to add a

permission key for each of these, and have it on the * group in the default
configuration. This would be more flexible, allowing any configuration (not just
sysops, but perhaps all logged-in users, or another special class).

What will be your proposal for such a permission key / group name ?

(In reply to comment #2)

... Better would be to add a > permission key for each of these, and have it

on the * group in the default

configuration. This would be more flexible, allowing any configuration (not just
sysops, but perhaps all logged-in users, or another special class).

My proposals for permissionkeys as suggested by Brion:

• ['listusers']
• ['listcontributions']

I'll soon publish a new patch taking Brion's suggestions into account.

Created attachment 838
Revised patch for REL1_5. Introduces new permissionskeys 'listusers' and 'listcontributions'

attachment CVS-REL1_5.diff ignored as obsolete

changed title

Created attachment 879
patch, revisited and revised: allow any user to list the own contributions regardless of the permission key

attachment x.diff ignored as obsolete

small additional fix to disable the display of "Contributions", when the user is not entitled to see the contributions
of others due to permission restrictions:

In SkinTemplate.php about line 860 add the marked lines

		if( $this->mTitle->getNamespace() == NS_USER || $this->mTitle->getNamespace() == NS_USER_TALK ) { 
			$id = User::idFromName($this->mTitle->getText()); 
			$ip = User::isIP($this->mTitle->getText()); 
		} else { 
			$id = 0; 
			$ip = false; 
		}

+
+ # disable "list contributions" in the toolbox, if the user is not allowed to use it
+ if ( !$wgUser->isAllowed( 'listcontributions' ) && ($wgUser->getId() != $id) ) {
+ $id = 0;
+ $ip = false;
+ }

clean and complete patch on request

avarab wrote:

Eugh, seems pretty specialized stuff, I think it would be better to make it an
extension.

(In reply to comment #9)

Eugh, seems pretty specialized stuff, I think it would be better to make it an
extension.

Avar:
some few arguments

• introduction of these additional permissionkeys was suggested by Brion (

http://bugzilla.wikimedia.org/show_bug.cgi?id=3294#c2 )

• I think, these two permissionkeys are useful in a broader sense (admittedly

not necessarily for wikipedia, which I know is the main target of MediaWiki)

• the additional code is short
• I don't expect that more of such "privacy" keys are needed

avarab wrote:

(In reply to comment #10)

(In reply to comment #9)

Eugh, seems pretty specialized stuff, I think it would be better to make it an
extension.

Avar:
some few arguments

• introduction of these additional permissionkeys was suggested by Brion (

http://bugzilla.wikimedia.org/show_bug.cgi?id=3294#c2 )

• I think, these two permissionkeys are useful in a broader sense (admittedly

not necessarily for wikipedia, which I know is the main target of MediaWiki)

• the additional code is short
• I don't expect that more of such "privacy" keys are needed

The reason I suggested that you'd implement this as a hook/extension is that
this is an example of something that would ideally be one. This is not something
most users would require in the default distribution. The reason the hook system
exists is so that we won't have code that looks like:

"""
global $SomeSpecializedStuff, $SomeSpecializedStuff2, $SomeSpecializedStuff3, ...;

if ($SomeSpecializedStuff)

...;

if ($SomeSpecializedStuff2)

...;

if ($SomeSpecializedStuff3)

...;

...
"""

Rather you can just have

"""
if ( ! wfRunHooks( 'HookForAnyPurpose', array( &$this, &$that, ...) );

return;

"""

which allows *everyone* to do *anything* at that point in the execution without
bloating the main code. It reduces maintenance for everyone involved and PHP
won't have as much stuff to parse, it's a win-win situation and I really don't
see what anyone would have against it.

Anyway, I've implemented the hooks and extensions for this bug in CVS HEAD, you
can find the extension in the Contributionsviewpermission directory in the
extension module in CVS.

Marking this as FIXED in CVS.

avarab wrote:

Removing bogus dependancy.

(In reply to comment #11)

The reason I suggested that you'd implement this as a hook/extension is that
this is an example of something that would ideally be one [...]
Anyway, I've implemented the hooks and extensions for this bug in CVS HEAD, you
can find the extension in the Contributionsviewpermission directory in the
extension module in CVS.

Avar,
I fully agree.
This is great news; I am willing to study it and to learn for the future. It
also enables me to work in conformity with you developers.

Thanks again
Tom