Erasing a person, and what stays

A customer asks you to remove everything you hold about them. This page is how that is done in the panel, what it refuses to do, and the one thing it keeps.

Personen → the person → Privacy. Two things live there: the file, and the erasure.

First: take the copy

Download the file before you erase, not after. It is the record of what you held, it is what you send the person who asked, and after the erasure it cannot be produced again. The download is audited under your name.

The erasure is the last step, not the first

Press Erase… and the panel counts what is attached before it offers you anything. If something is in the way it says so and lists it, with the reason for each:

• Memberships. Ending somebody's access is a decision that gets recorded as itself. Remove the memberships from the customer's member list first; the log then says an administrator ended their access, which is what happened.
• An open ownership transfer. Settle or cancel it. A transfer to somebody who is about to stop existing has to have an answer.
• A customer account on their login. This is the widest one. In the older model a customer account hangs directly off a login, and removing the login would take the customer account — and everything under it — with it. Close or hand over the hosting first.

None of these is a technical obstacle to route around. Each is a decision somebody has to make, and making it separately is what leaves a record of it.

What it does

When nothing is in the way, the dialog shows two numbers — how many rows go and how many stay — and asks you to type the person's address. That is not a test of typing; it is to make you look at which person you are erasing.

Then, in one transaction:

• the login goes, with the password, the second factor, the passkeys and the recovery codes;
• every session ends, including any session they had opened while signed in as somebody else;
• notifications, preferences, push and Telegram links, set-password links, API keys that acted as them, single sign-on hand-offs, conversations with the assistant and what those cost;
• the person record itself, with the address on it;
• on rows that are about something else — a rollout they started, a package they own — only their name comes off. The row stays.

It happens whole or not at all. Before it commits, the panel re-reads every place it was supposed to have emptied and counts what is left; anything still there rolls the whole thing back and names the table. The receipt you get is that count, not a promise that a delete was issued.

If it fails, nothing changed. There is no half-erased person to finish later: deal with what the message names and run it again.

Checking the machinery, on the panel host

Two commands, and neither of them changes anything. The first compares the list of places a person's data lives with the database's own schema, in both directions — a column the schema has and the list does not is a place an erasure would step over. Run it after a migration.

corecp-panel privacy check --config /etc/corecp-panel/panel.yaml
corecp-panel privacy terms --root /srv/corecp/src

The second prints every retention period this build enforces, which is the same table the customer-facing page shows.

What stays, and why

The audit log keeps the address that acted. Every operation this person carried out stays in the log with their address and the address they were at, for as long as the panel exists.

That is a decision, not an oversight. The log is chained: each line carries a hash of the one before it, which is what makes it evidence rather than a file. Editing a line breaks the chain, and a security record its own subject can edit is not a record. So a name in the audit log survives the erasure, the person asking should be told that, and the customer-facing page says it in plain words.

The erasure itself is the last line written about them.

Somebody with no login

One kind of person cannot be reached from the Personen list: somebody invited after the identity change who never had a legacy login. The routes accept a person id as well as a login id, so an administrator can still export and erase them — over the API, or by finding the id in the customer's member list.