Last modified: 2011-03-13 18:06:49 UTC
I have added a switch, which disables the * list of all users * list of other user's contributions for non-sysops. This is mainly for use of MediaWiki in enterprises. For Wikipedia, $wgEnhancedPrivacy = false;
Created attachment 836 [details] patch
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 [details] Revised patch for REL1_5. Introduces new permissionskeys 'listusers' and 'listcontributions'
changed title
Created attachment 879 [details] patch, revisited and revised: allow any user to list the own contributions regardless of the permission key
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
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
(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.
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
