Deleting a member
A member can be deleted in two completely different ways, and they leave the account in very different states. Knowing which one happened answers almost every question that comes up afterwards.
| Who does it | Where from | What happens to the member | |
|---|---|---|---|
| Hard delete | An admin | Admin portal | Permanently erased from the database |
| Soft delete | The member themselves | Their own profile page | Stays in the database, switched off |
Both write a record to a table called member_deleted. That is the part
that catches people out, and it is covered at the end.
Scenario 1 — an admin deletes a member (hard delete)
This one is permanent. The member’s row is removed, along with their logbook, payments and login details. It cannot be undone and there is no restore button.
Who can be deleted
There are two admin routes and they allow different things.
From the member’s page in the admin portal, only Flyers and Pending members can be deleted outright. Anyone further along has to be transferred to another member first, so their logbook entries and approvals move somewhere instead of vanishing.
From the Member Delete tool (Tools → Member Delete), any role except Admin can be deleted, in bulk, with no transfer. This is the blunt instrument, meant for clearing out accounts that should never have existed.
Admin accounts cannot be deleted by either route.
Take care with the bulk tool. Deleting an instructor, trainer or coach destroys their logbook entries outright. Those entries are not moved anywhere, and other members’ records that referred to them will point at an account that no longer exists. Use the transfer route when the history matters.
What happens, step by step
-
A record is kept first. A row is written to
member_deletedwith the member’s ID, role, currency flags, approval levels and the date. This happens before anything is removed, so the record survives. -
The profile photo is deleted from file storage.
-
The logbook is cleared, one entry at a time, along with each entry’s instructor comments and confirmation checkboxes.
-
Everything else is erased in a single database operation covering eleven tables:
- the member themselves
- their logbook entries
- payments and payment status
- login records, social logins, passcodes, security answers
- notification read-history
- their member history
These go together — if any part fails, none of it is applied.
What survives
Only the member_deleted record:
- member ID and role
- last visit date
- currency flags (flyer, coach, instructor, trainer)
- approval levels
- the date the delete happened
It does not hold the name, username or email. After a hard delete the record tells you that member 12345 was deleted and what level they had reached, but not who they were.
Scenario 2 — a member deletes their own account (soft delete)
Members can delete their own account from their profile page. Despite the wording on the button, nothing is erased.
Who can do it
Only Flyers and Pending members. Anyone further along is refused, with the message “Only flyer accounts can be deleted”.
What happens
- their role changes to Deleted
_deletedis added to the end of their username and email- a
member_deletedrecord is written, exactly as in the admin delete - their cached data is cleared so the change takes effect straight away
What survives
Almost everything. Their logbook entries, payments, payment status and profile photo all stay exactly where they were. The account is switched off rather than destroyed, and the member row is still there to be looked up.
Adding _deleted also releases the original username and email. Sign-up
looks for an exact match, so once the stored value has changed the person is
free to register again later with the same details.
Telling the two apart
Both scenarios write to member_deleted, so that table alone cannot tell
you what happened. It records that a delete was requested, not that the
member was destroyed.
To find out which one it was, look the member up by ID:
| What you find | What happened |
|---|---|
| Member does not exist | Hard deleted by an admin |
Member exists, username ends in _deleted, role is Deleted | Soft deleted by the member themselves |
This is why member_deleted can hold rows for members you can still open
and read. Those are self-service deletions, not failed admin ones.
Things worth knowing
A hard delete cannot be reversed. There is no archive of the member’s
logbook or payment history — only the small member_deleted summary.
A soft delete can be reversed by an admin, by changing the role back and
removing the _deleted suffix. Nothing was lost.
Deleting is not the same as banning. A banned member keeps everything and can be restored. A hard delete is final.
Members with two-factor authentication set up cannot currently be hard deleted. Their authenticator records block the removal. In practice this only affects admin accounts, which cannot be deleted this way anyway.