Fully delete user in Galaxy

I would like to fully delete a user so I go into the admin panel and delete them, while the wording is not ideal (“delete” is more like deactivate since nothing actually gets removed…), fine, I get that they are now unable to login. Now I want to really totally nuke the account, so I purge them. Why do they still exist in the GUI as purged. They are still in the database so that email cannot be reused. Can someone explain why purging does not actually fully purge them? Is there a way to completely delete a user?

Also, if I do not create an account for someone manually, but they have a valid local user and login via PAM, why does their account then get listed as purged…

Hi @mjbludwig

The “delete” and “purge” (permanently delete) states for an account follow the same usage as most of Galaxy’s GUI functions: delete can be undeleted to active and purged cannot.

Please see the configuration option here: GDPR Compliance — Galaxy Project 22.01.1.dev0 documentation

Hi Jennaj,

I get the gdpr bits but this does not help my underlying issues.

  1. I have a user account that has been purged but I would like to reuse that email and username. As you state, a purged account cannot be reinstated which makes sense but then how can I make a new account re-using the same username and email?

  2. When an account does not exist, i.e. I have not made one in the admin panel, a user with active NIS (in my case) credentials can still login and their account seems to be created but then it only seems to exist in a “purged” state. Can I change this behavior so that the accounts are not automatically just held in this “purged” state?

Hi Morgan

Assuming you have a functional and up-to-date backup of your Galaxy PostgreSQL database, you can try and manually change the ‘galaxy_user’ table for the purged account, e.g.: change the email and username by adding a “_” to both (do not delete the line!)
Though, be very careful when manually change the database

Regards, Hans-Rudolf

1 Like

I can successfully modify the entries and once that is done, upon first login using the original account, I can see new accounts being made but the duplicate error still arises.

Is there some sort of cache somewhere or another part of the database where it might check based on email? It looks like that is what it is matching on as the key its mentioning is: DETAIL: Key (name)=(arhode05@tufts.edu) already exists.


1 Like

Hi @mjbludwig

Probably. This kind of artifact is present in the non-GDPR servers I’ve worked with and behaves how you describe.

The method @hrhotz describes will definitely work. I do this through the admin UI for convenience but also don’t need to process batches. I’m not sure how many tables that purge query touches but it works, and the code could be reviewed if changing it directly on one table is not enough. I also add a bit more to both the email and publicname, usually something like _description.

The admins of the UseGalaxy.eu server have GDPR mode enabled (GDPR | GDPR Compliance Documentation), and account email addresses are reusable after a purge. Maybe they are including some extra cleanup step if setting your server up in that mode is not enough.

Let’s ask another expert: ping @bjoern.gruening. Once we know what is going on, maybe the admin purge in non-GDPR mode can be improved, too.

For reference, I currently do not have my galaxy with enable_beta_gdpr enabled. With that off though, purged users still get renamed with some sort of hash for username and email it looks like. Noticing that I also went and added _xxx to those entries in the database in case Galaxy was hashing incoming account creations and checking them as well.

Correct – the email, username (aka publicname), and password are all anonymised. But attempts to create a new account with that previously used email result in a sort of zombie account that can’t actually be used.

A ticket for implementing a full purge (actually removing rows, rather than just modifying keys) is here. Upvote and follow if interested: Allow purging users, jobs completely from the DB · Issue #13738 · galaxyproject/galaxy · GitHub

Ah, ok. If for some reason GDPR mode doesn’t allow email reuse, that would be a bug as far as I know.

Try adding _xxx before deleting/purging instead, and leave the hashes intact. That alone should release the original email and username for reuse without more changes. I do this through the admin GUI and it works fine. Using Bioblend to interact with that function via the API should be possible and avoids guessing where to make changes to database tables directly.

Hi Jennaj,

When you refer to “zombie account” are you referring to the accounts that are being created (once I rename the bad ones) and look correct but are still being blocked due to duplicates? That is clearly a bug then as well? If an account is being rejected from logging in, why was it created in the first place?

Again, originally I deleted an account foo then I purged it, following that subsequent logins trying to use the same email/username were blocked due to duplicate accounts. That sounds like an original bug in purging?

FWIW, Trying to rename the “zombie” accounts via the GUI results in an API error:

Traceback (most recent call last):
  File "/cluster/tufts/galaxy/galaxyprod-pax/lib/galaxy/web/framework/decorators.py", line 320, in decorator
    rval = func(self, trans, *args, **kwargs)
  File "/cluster/tufts/galaxy/galaxyprod-pax/lib/galaxy/webapps/galaxy/api/users.py", line 437, in set_information
    private_role.name = email
AttributeError: 'NoneType' object has no attribute 'name'

^ from galaxy.log

That git issue is definitely a good discussion for removing extraneous data from old users but is definitely complicated.

Having an account purge/anonymise enough by an admin function, to allow registered email reuse, is a valid use case. GDPR mode does that, and other use cases were more about cleanup of old data to recover space, example: purge Galaxy users and their data/histories/data libraries - recommended approach? · Issue #6603 · galaxyproject/galaxy · GitHub.

If GDPR mode does not do what you need, you could break the request out into a new issue ticket. Maybe it can be addressed separately from the “purge all old account everything” ticket.

Roger that. I will restart my server in gdpr mode and test!