Last modified: 2010-04-18 09:04:42 UTC
There is at the moment (to my knowledge) no proper mean to close an account on a private wiki where an account is needed to view the content. Such wikis are often private because they contain sensitive information that not everybody should be able to access. It often happens that such accounts are attached to users who have a temporary status in the organization. When this status expires, it is often desirable to remove the access of these people to the private wiki. An ugly way to do this is to delete users manually in the sql table. == Proposed solutions == An idea would be to create a new usergroup named "expired" that could be set and removed by bureaucrats through [[special:userrights]] for private wikis (which have $wgGroupPermissions['*']['read'] = false;). Users in this group should not have the "read" right ($wgGroupPermissions['expired']['read'] = false;). The "expired" usergroup should override the implicit read permission $wgGroupPermissions['user' ]['read'] = true; Another solution would be to block the user, make his cookie expire and check if the user is blocked when he tries to log in.
You can do this by creating a group with read permission and denying read permission to anyone outside that group, e.g.: $wgGroupPermissions['*']['read'] = false; $wgGroupPermissions['user']['read'] = false; $wgGroupPermissions['trusted']['read'] = true; In MediaWiki, it's impossible to override a 'true'.
Thank you for your quick answer. However, the workaround you propose is not workable on a large scale, since that would mean changing groups for all users except those who expire. I reopen the bug since the "invalid" applies to one of the solutions I proposed, it doesn't apply to the bug itself which still exists.
Please have a look at the PasswordReset extension ( http://www.mediawiki.org/wiki/Extension:Password_Reset ). A sysop can invalidate the passwords from users. It seems it would solve your needs.
Thank you. It is indeed a possible solution. Though, it seems this action "sets an invalid password hash". This definitive password scrambling offers no possibility to reopen the account later. The account closing should be reversible in case the user is later allowed to view the content again (the same way a blocked user can be unblocked and allowed again to edit the content). If a separate usergroup isn't workable, maybe an option "Prevent user from logging in" could be added to [[Special:Blockip]]? And the logging in should be tweaked accordingly.
(In reply to comment #4) > Thank you. It is indeed a possible solution. Though, it seems this action "sets > an invalid password hash". This definitive password scrambling offers no > possibility to reopen the account later. The account closing should be > reversible in case the user is later allowed to view the content again (the > same way a blocked user can be unblocked and allowed again to edit the > content). > After our IRC conversation today I installed this extension and tested it locally. It is possible to a) set a new password b) disable the account by a special kind of password scrambling In case of b) the user is unable to request a new temp password per email. But the sysop can reopen the account by setting a new password.
Thank you very much! Marking the bug as fixed then.
(In reply to comment #2) > Thank you for your quick answer. However, the workaround you propose is not > workable on a large scale, since that would mean changing groups for all users > except those who expire. I reopen the bug since the "invalid" applies to one of > the solutions I proposed, it doesn't apply to the bug itself which still > exists. It would be a one off mass change though, then just who evers account created after that. You could even do a script that you feed its the name in a file and it does it via the api or the likes for the mass change.
