This should go into the docs:

To remove a user:

1. Edit the data/.htpasswd file to delete their entry
2. Remove their topic files: data/Main/FredQuimby.txt and data/Main/FredQuimby.txt,v
3. Remove the FredQuimby line from the Main.TWikiUsers topic
4. Remove user from all groups and from all the ALLOWWEB/ALLOWTOPIC... declarations, if any.
   Note: Otherwise this is a security hole as the first one to re-register with this name will be granted the permissions of the previous user.

(From Support.DeletingUsers)

-- PeterThoeny - 07 Sep 2002

It would be nice to have a prepared TWiki-Admin page in the TWiki shipment, where this is based on SEARCH-links already.

-- MartinRaabe - 07 Sep 2002

I do not really delete users, as this breaks the automatic links in everything they signed... I just remove the entry from .htpasswd, add a comment to the users hometopic, and make it readonly on OS level (the latter beeing a matter of taste - you could also set it to changeable only by the admin group.
-- FlorenzKley - 19 Feb 2003

This is rather interesting -- I'm guessing that FlorenzKley's procedure is aimed more for people who will permanently be gone, as opposed to removing people who have some problem with their password and need to re-register to get things squared away. It seems like there is some kind of Catch-22 in this whole thing which I can't quite articulate immediately. Or maybe people no longer have to be unregistered and then re-register if they've forgotten their password (and, IIRC, their home page has to be deleted to allow them to re-register?) -- I'll have to look that up. Anyway, sorry for the rambling -- hopefully I'll see this again tomorrow and either delete it or put a more cogent statement here.

-- RandyKramer - 20 Feb 2003

Well, I like the rambling because it sparked my thoughts. There are several things that a person might call "delete". For example,

• purge all traces of account (do "something" with links, or replace home page with a "no tresspassing" sign
• disable account (disallow logins, remove from groups)
• remove home page and login information in anticipation of imminent re-registration.

All of these can involve adding comments to the home page if not deleting it outright.

Personally, I want to be able to do all/any of these from a web interface. And they are separate enough functions that I would like them all, not just the one voted "most likely to please". But then I'm a creepy featuratizer.

-- BruceMcKenzie - 11 Apr 2003

First kick at the documenation can: MaintenanceGuide

-- MattWilkie - 21 Jul 2003

why cant we use remove topic to remove a user.it allows unchecking or checking of links for deletion or total purging. I tried this and it sent the user to Trash but the name still comes up in the list.

-- MarkAutumn - 23 Sep 2003

Whilst building the RegisterCgiScriptRewrite, I noted that there alreaddy exists bits of code for this - I don't know whether its tested, but it certainly is not documented here.

-- MartinCleaver - 05 Nov 2004

I attached my script to remove users to show how user deletion is handled at our site:

• Users normally do not vanish without a trace - content they participated still links to their user topic.
• Their email address is removed from the user topic and the comment field is set to "Retired User" (maybe topic write protection and a more obvious tag would be desireable?)
• They are removed from all groups they are in - since access control is done on a group basis only this is sufficient i my case.

-- ChristopherHuhn - 13 Jun 2005

We should pull this in in Ed. Useful to invoke via the email from registration to the admin so that the admin can quickly pull the reg should they turn out to be a useless spammer.

-- MartinCleaver - 21 Sep 2005

ChristopherHuhn, thanks for your script above: However it doesn't appear to work completely with TWiki 4.01. The email address is removed, but the comment field is not set at all.

If the user posted spam topics, how to remove them all with a modified version of this script? Perhaps an added parameter could be passed to the script specifying that all content the user created should also be removed.

-- RonMiller - 10 Mar 2006

I just uploaded the current version of my twiki-remove-user script. I added a purge function to delete users mentioned nowhere else. Anyhow I don't think there's a sane way to automatically purge users that partcipated in (or spammed) topics apart from their user topic.

Unfortunately I cannot yet test if it works with DakarRelease. Maybe the structure of the comment field has changed?

-- ChristopherHuhn - 13 Mar 2006

Yes, it appears the structure of the data in user files has changed. I've modified the sed line on my end to work with TWiki 4.01, and handle HomePage, OrganisationName, and OrganisationURL as well.

sed -e "s/\(name=\"Email\".*value=\)\".*\"\(.*\)/\1\"\"\2/;s/\(name=\"Comment\".*value=\)\".*\"\(.*\)/\1\"Retired User\"\2/;s/\(name=\"HomePage\".*value=\)\".*\"\(.*\)/\1\"\"\2/;s/\(name=\"OrganisationName\".*value=\)\".*\"\(.*\)/\1\"\"\2/;s/\(name=\"OrganisationURL\".*value=\)\".*\"\(.*\)/\1\"\"\2/" $TWIKI_DATA/Main/$USER.txt > $TMPFILE

-- RonMiller - 13 Mar 2006

(Five years later!) filed as TWikibug:Item4905

-- MartinCleaver - 29 Oct 2007

Admitted it should be a core feature. But how about making it an extension.

-- MichaelDaum - 01 Nov 2007

This is certainly a feature that should be added to the TWikiUserMappingContrib.

-- SvenDowideit - 29 Dec 2007

There is more than one use case to removing users, e.g. it should be configurable.

Use Case 1: Public websites

• User homepage is removed
• User is removed from TWikiUsers topic
• User is removed from TWiki groups

Use Case 2: Intranet

• User homepage remains (so that signatures remain intact), but content is replaced with a message such as: "Left company in 2007; new contact is FredQuimbly."
• User is removed from TWikiUsers topic
• User is removed from TWiki groups

There are possibly more uses cases. Feedback?

-- PeterThoeny - 02 Jan 2008

Use Case 3: disable or block a user

• currently implemented by changing the password and email address entry in the htpasswd file

-- SvenDowideit - 02 Jan 2008

I wonder if there's anyone out there that would like to use this as an introduction to the TWiki Core code

-- SvenDowideit - 06 Feb 2008

Instead of deleting user accounts they should be archived/moved into an _Alumni web.

Another important point is, how to deal with topic history. If you register a new account JoanSmith and there was an account of the same name before, she appears to be the author of former revisions that her namesake actually was.

And then there might be auxiliary topics a user generated for him/herself ( JoanSmithSideBar, JoanSmithCV and the like). That's rather application specific, and somewhat needs a way to be configured / hooked in, e.g. using a deleteUserHandler().

-- MichaelDaum - 07 Aug 2008

This obviously applies to the TopicUserMapping, but what about other user mappers?

-- CrawfordCurrie - 24 Nov 2008 - 10:10

It looks like I'll be implementing this for TopicUserMapping for use in FoswikiApplicationsContrib - I'm building a tabular UserManagementApplication.

-- SvenDowideit - 18 Feb 2009

Note that Tasks.Item772 documents the perils of "edit .htpasswd" - which is a very bad thing. Whatever you do needs to include the proper locking. Otherwise, you will eventually get burned.

-- TimotheLitt - 18 Feb 2009

I am not sure what this proposal is all about.

There is no spec. Just a discussion that goes back to 2003.

It is impossible for anyone to say if they are for or against and we do not have the chance to comment on the implementation.

If this goes into an extension made by Sven there is no need for a feature proposal because Sven can do whatever he likes in his own extension.

If this is a feature for core then I have no clue what it is.

My personal view on the feature in general is that especially for public Foswiki installations you have to remove spammer type users regularly. They come. They spam and they come back and they spam more.

The admin could use an application that enables the admin to remove a user and select what he wants done, maybe with checkmarks for each step

• Remove user from .htaccess (if password manager allows so this becomes a new feature in password managers)
• Block password in .htaccess (assign the admins email address and invalid password string)
• Remove the users entry in WikiUsers
• Remove the users topic in USERSWEB
• List the topics that has the LAST revision made by the user and offer both a normal view and a delRev link for each of them (I would not want this in bulk)

Now in an intranet environment in a company the admin would

• Not want to remove the users topic and leave hundreds of broken wikiword links
• Would not need to revert revisions of any topics.

And unless you use the .htaccess method for passwords you would not need to do anything when a person leaves the company other than maybe from the WikiUsers topic and for that there is no need for a big application. But it does not harm that it is there.

So I am supporting the whole idea. But again - people need to know what they are accepting.

The activity on Tasks.Item4905 is a good documentation update. Improving documentation needs no feature proposals.

-- KennethLavrsen - 21 Mar 2009

Follow-up. No response whatsoever to this proposal.

The fact that this was never a feature proposal in the first place (not a trace of a spec) makes me call it rejected.

It is not a serious proposal and we are wasting our time

-- KennethLavrsen - 17 Feb 2010