Skip to Content
Business logicBusiness logic: Deleting a member

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 itWhere fromWhat happens to the member
Hard deleteAn adminAdmin portalPermanently erased from the database
Soft deleteThe member themselvesTheir own profile pageStays 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

  1. A record is kept first. A row is written to member_deleted with the member’s ID, role, currency flags, approval levels and the date. This happens before anything is removed, so the record survives.

  2. The profile photo is deleted from file storage.

  3. The logbook is cleared, one entry at a time, along with each entry’s instructor comments and confirmation checkboxes.

  4. 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
  • _deleted is added to the end of their username and email
  • a member_deleted record 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 findWhat happened
Member does not existHard deleted by an admin
Member exists, username ends in _deleted, role is DeletedSoft 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.

Last updated on