=====How to remove users=====

<<See **UserAdmin**<<::c::

I would like to share with you some thoughts on the problem of **how to remove registered users**.
This has maybe little interest for traditional wikis (meant to be collaborative tools with //unrestricted access//), but is certainly relevant for many other possible uses of a wiki engine (e.g. a //moderated// or //members-only// CMS) 

== Why on earth should I want to delete a user? ==

There are cases in which a wikka administrator might be willing to delete a user:

~-**spammers** - users that exploit wikis as link farms for boosting their websites;
~-**vandals** - users removing whole pages just for fun;
~-**fake users** - users who created a "throw-away" account just for testing the wikiengine; 
~-**obsolete users** - depending on the use of a wiki, there are cases in which users become inactive after a certain time (imagine a wiki engine used as an intranet tool for a group/organization whose members are renewed every year and in which content is reset every year).

So far, the only way to remove users is to manually delete entries from the ##wikka_users## table, which raises some major problems (see below) and requires some basic knowledge of MySQL/phpmyadmin.
I think that a wiki-based system for managing user deletion might interest many potential wiki administrators.

== Problems with user deletion ==

Removing users has a number of consequences similar to removing //pages//. Wiki users are not atoms, they are embedded at different levels in a wiki engine: they appear in the history of wiki pages as contributors or page owners, in comments, in ACL lists etc.
Simply deleting an entry in the user table leaves won't help remove their 'presence' from the wiki and can create inconsistencies in the wiki.

== Active/inactive users ==

A possible way to avoid the problems above is to think of user deletion as //user inactivation//, i.e. handling a list of active users and inactive users (much as valid vs. blacklisted referrers). This solution has a number of benefits:
~1) Removing users takes just one click to shift them from the active to the inactive list.
~1) Users can be reactivated on demand:  their logs and pages are still available in the database. 
~1) The overall consistency of the wiki is saved. One just needs to implement a function that checks the status of a user (active/inactive) before performing operations like displaying a page content, a comment or an ACL interface. This should be discussed in
more depth.

== Banning users by IP ==

A different but related issue concerns the possibility to remove users not by username but by IP address. This might be useful in the case of vandals or spammers that can create an infinite number of useraccounts. Requiring [[WikkaAndEmail | email validation]] on registration can be a good solution, but perhaps the best solution would be to store the IP of the last connection in a dedicated field of the ##wikka_users## table. Dozens of users connected from the same IP address might draw the Wikka administrator's attention;

Any ideas/thoughts on these issues before I start toying with some code?

-- DarTar

''A few thoughts...
==Why on earth should I want to delete a user?==
~-**Spammers**: During my recent Wiki rambles I found some good throughts on [[http://www.usemod.com/cgi-bin/mb.pl?WikiSpam | WikiSpam]], discovered [[http://chongqed.org/prevent_spam.html | Fighting back against wiki and blog spam]] and many other pages on this subject. Basically, there are many ways to fight back, but an important way is to discourage ""WikiSpam"" in the first place, by making sure that 1) Page History and RecentChanges are out of bounds to all search engine robots, and 2) do the same  for the SandBox: just insert the appropriate ##meta## tag, and leave a note on those pages. Another approach I've seen is to lead all external links through Google's own redirector but of course this works only to prevent indexing by Google and not (necessarily) other search engines. The more spammers are discouraged, the less you'll have to do about them.
~-**Vandals**: Should be "banned" as well as "deleted". How, is the question. Reverting a vandalized page isn't quite enough; I was thinking about a "de-deface" action for a WikiAdmin which would 1) set the "current" flag to the previous page version //as well as// 2) **delete** the defaced page version. The Wiki community could just revert but it takes a number of actions to do that; a special action for a WikiAdmin could be faster and more thorough by not "leaving a trace" of the vandalism in the first place. (But see also the remarks above about denying access to SE bots to history and changes.) In principle, fast action on defacement will discourage the vandals - from what I've read it seems to work.
~-**Fake users** and **Obsolete users** I would consider these as two variants of "inactive users". The [[http://www.mantisbt.org/ | Mantis]] bug-tracking system has a "purge" action for the administrator that deletes accounts of users who have created an account but never logged in (after a certain -configurable- period); I could imagine something similar for Wikka. Something along the lines of //automatically// setting a user as "inactive" after a period of "inactivity". Needs more thought on how this would apply, exactly...

== Problems with user deletion==
I quite agree this would be a problem if done directly (manually) on the users database - **//unless// the user has never actually created or edited any content (not even comments)**. Otherwise inconsistency of the database could easily result; should be avoided unless you **really** know what you are doing and have intimate knowledge not only of the database structure but also how it is used.

==Active/inactive users ==
I like this a lot better - and see also my remark about "fake" and "obsolete" users above: making some users //automatically// "inactive".
"Users can be reactivated on demand" - actually I think an "inactive" user should be allowed to login (anyway) and be //automatically// be "activated" again once s/he actually edits or contributes content (or at least content other than comments). This requires more thought about a precise mechanism, but my idea is that for "naturally" inactive users, inactivation and activation should be automatic and dependent on "behavior" so that only spammers and vandals would really require action by a WikiAdmin.
(If I go on vacation for more than two months --and that happens :)-- I might be temporarily "inactive" but as soon as I'm back and actually //do// something to a Wiki, I would be "active" again. On some larger and well-established Wikis people might actually be "inactive" for a year or more, and then return because they feel they can/should make a contribution again.)

== Banning users by IP==
**BIG RED FLAG.** There might be cases where this is necessary, but it really should be a desperate last resort, IMO. Why? Because an IP address does not necessarily **identify** a user. First, //most// dial-up users and //many// broadband users will get a new IP address each time they establish a new connection. In addition, many large access providers (AOL is one notorious example, but by no means the only one) don't have enough IP addresses even dynamically (by connection) to go around their number of users: what they do is give a new IP address for every **request** sent to a server (the proxy server on their network effectively does that). And then there are the corporate networks that internally have many isers, but externally (as their interface to the Internet) display only a single IP address. As a result (mostly due to the scarcity of IP addresses under ""IPv4"), a single IP address may be used by many users, and a single user may have multiple IP addresses even during a //single session//. Banning by IP address could thus result in banning a multitude of people, or a multitude of people only part of the time. Rarely effective, and often victimizing completely innocent users. This wouldn't matter all that much for a little informal poll, trying to prevent people from voting twice; but for **denying access** it's not practical, not user-friendly, and will often mis-fire.
"Requiring email validation on registration can be a good solution." Only partly, I think; and it would also make a Wiki even less "open" than one that doesn't even require registration to get "edit" rights. It might be valid for some Wikis, but at the very least it should be a configuration option.

Thanks for bringing this up though, DarTar! I had been thinking about some of these isseus already. I hope to see more discussion on this!''
-- JavaWoman

==My two pennies==
I would also like the ability to remove users. From my point of view, I am using the wiki on a corporate Intranet and what with people leaving and being made redundant :-( I want to be able to tidy up the users (''of course if I am one of those being made redundant, I won't be that bothered any more!''). I don't see too many problems with removing them from the users table if at the same time the ownership of any of their pages is transferred to another user. The history of the pages is still valid as you store the user name and not an id, so you can still see that they edited a page even though they are no longer in the user table. You could at the same time delete their user page (and all revisions). The biggest problem that I see is when you start using other features that are not included in the standard wiki release e.g. PageWatches, where you are notified by email if a watched page changes; the user would have to be removed from this table as well. This is where the real inconsistencies in the database could occur. For this reason, having an active/inactive flag would seem the better way to go, then anyone writing new features or modifying existing ones can take the flag into consideration.

==Email validation==
I really would like to see the email validation on registration as a feature (this time not for a corporate intranet, but for my own web site), and I agree that this should be a configuration option. Anyone who seriously wants to contribute to a wiki would have no problem waiting a few minutes for a validation email, whereas a vandal would probably be put off. If they are still willing to vandalise or spam after being validated, their email address could be used to ban them.

--PeeJay

This has been enlightening.  I found this page trying to figure out why my UserAdmin delete function did not work.  The fact that this page has not been address in nearly 5 months is hopefully not an indication that user deletion is abandoned.  

I agree with many of PeeJay's comments.  My wiki is used to develop training material.  I already have need to delete a duplicate user account (well not exact duplicate but it's the same user).  The idea of keeping the user list cleaned up is something important to me.

I hope I don't have a problem with vandals.  If I did, the ability to block their email address and reset all of their changes (as it they never entered the site in the first place, would be highly desirable.

--MikeBev


----
CategoryDevelopmentAdmin