User Deletion

[lukasjuhrich]

We should think about a procedure to delete users. The unix_account might be considered independent of this question.

---

Related Tasks:

• Identify users who could be archived #470

---

(added later)
Subtasks:

• Add design document describing three phases of archiving (scrubbing, freezing, deleting)
• Implement more privacy-oriented unix account tombstoning with hashed login values #597
• Implement && test phase 1 (data scrubbing)
• Implement && test phase 2 (freezing)
• Implement && test phase 3 (deleting)

[lukasjuhrich]

This touches the following behaviors:

Use Case: User moves out continuing use of services

• The room reference will be removed
• We need to know the current address after the dormitory for that.

Use Case: User moves out without continuing use of services having nonzero balance

• We need to know the last known address for the finance information (de facto the former rooms address) → Just leave what's in user.address
• The splits still need to be associated to some user, so we desire archiving over deletion
• Open Question: Do we want to retain group memberships to know what the actual periods of formal AGDSN membership were? What about UserLogEntries?

When moving out, the following follow-up action should be considered:

Use Case: Closing of finance account

• A user without a room or services and with a zero balance in his account could be deleted
• The account would still exist, so we still retain the transactions while discarding unneccessary personal information.

Use Case: limitation of claim („Verjährung“)

• A user with a nonzero finance balance could be deleted as well after three years due to limitation of claim.
• Open Question: It's still not clear how we want to deal with this regarding the financial process.

Unclear: How to deal with former admins

A lot of management entities like logentries or an MT940Error reference a processor. It is unclear how that should be handled when the former admin e.g. demands deletion of his/her data.

Possible realization of „archiving“

One could consider splitting up an ArchivedUser from a User both inheriting from an AbstractUser (RIP naming) following the following criteria:

• a User is characterized by the ability to live in a room, being referenced for UserTasks, requiring a UnixAccount, and having Hosts and all the technical stuff to be introduced in NAT Model, Act I #330 NAT Model, Act II #331 Support for centralized NAT #73 etc.
• an AbstractUser is characterized by the ability to have a finance_account, by requiring a name, and requiring an address. As mentioned above, possibly also by the ability to be referenced by Memberships and LogEntries
• An ArchivedUser is characterized by the ability to… optionally have a unix_account? At least nothing of importance here.

Depending on the technical details, we could possibly drop the sibling construction and opt for a parent-child construction ProFormaUser←User – „archiving“ would the mean dropping the polymorphic User identity of a ProFormaUser.

[lukasjuhrich]

We want the following three-step model:

1. Marking a user for deletion by adding them to a „to be deleted“ group, which can deny all properties
2. „Archiving“ the user: Removing all log entries, Tasks, and Hosts (but not memberships, unixAccount and Finance data!)
3. Removing the user either 10 years after EOMembership or when the account is balanced.

[Lodifice]

Regarding 3: whatever is later?

[lukasjuhrich]

Yes, whatever is later. We want that both conditions are met (10y have passed + account balanced).

[lukasjuhrich]

The purposes of the suggested phases would be:

1. Enabling a confirmation step before irreversible things happen
2. Deleting as much data as possible while retaining what we need for backing up financial claims && membership data
3. Deleting everything when the requirements drop.

It's not clear what 1. means however. The risk factors basically are:

• The “filter” we choose to gather candidates for archiving picks up someone who shouldn't be there, and deleting hosts and logs of this entity would result in someone losing access.
• it picks up someone whose membership ended because of lack of payment, who contacts us and wants to be reactivated by applying for a new membership. Deleting logs of this entity would then result in the support team being unable to transparently see what has happened.

A benefit of decoupling 1. from 2. is that one can easily intervene manually by removing / adding the “to be deleted” membership.
Another question would be if realizing that with a membership wouldn't be overkill.

A last question would be: Do we want a manual audit mechanism for the users that are marked as “to be deleted”?

[lukasjuhrich]

The big, big question is what the qualifier for marking for deletion should be.

1. User.room is None would match too much, because (often active) members not living in a dorm anymore might be deleted
2. User.room is None and not User.hosts also matches too much for the same reason
3. User.room is None && there are no active group memberships finds too few users, because that does not catch cases where a user has e.g. been exempted from payments, and hence has one unbounded membership

Perhaps we should add a property keep_in_system to groups like Aktiv, Exaktiv, Mitglied, which we can do to augment variant 2?

[ibot3]

3. User.room is None && there are no active group memberships finds too few users, because that does not catch cases where a user has e.g. been exempted from payments, and hence has one unbounded membership

But the users that have a negative balance (and therefore may have the Zahlungsrückstand group) shouldn't be deleted anyways or only at a later point (maybe 5 years?

[lukasjuhrich]

The proposed lifecycle for users who have a negative balance would be:

1. Once they are not a member anymore (and are not „kept alive“ by some other qualifier such as „using services“ etc), they will be tagged as to-be-archived via some membership
2. After a lenience period (say half a year), the user will be archived in the sense of step two mentioned above. Finance and membership data will still exist.
3. At the latest ten years after EOMembership the data could be deleted, since due to §195 BGB the monetary claim vanishes after 3 years, and keeping the data for ten years is required by §147 AO (3).

I'm not quite clear over whether we actually need to keep the membership data for that long. Probably though, because it provides the basis for the monetary claims.

[ibot3]

After a lenience period (say half a year), the user will be archived

There is already a fixed date for this: At the end of the next year that follows the EoM.

Example:
Membership ends on 2021-07-01: Archiving will be done on 2023-01-01
Membership ends on 2022-01-01: Archiving will be done on 2024-01-01

[lukasjuhrich]

An important suggestion raised by @marcelb98: in the deletion process, we might want to give a PDF-printout of all the user-ids (+ corresponding logins) that have been deleted so that we know which of the paper forms can be destroyed. Note that some of the oldest forms did not even have a user-id printed on it, which is why we require a login.

As to not create any more unneccessary digital data, we should not retain that information digitally and print it out + add it to the binders with the membership info.

If there would be a way to avoid the login information that would be great; in that case, we might even go for an alternative workflow and just look which user ids are still in the membership table. We can obtain that estimate when doing the initial archiving and selecting for people who don't have the archived property.
I wouldn't expect a lot of people (hence user-ids) to be left.

[ibot3]

I don't know the current status, but I remember that the user-ids were added to the printed forms afterwards.
But I could also be wrong, so we should just take a look at some old forms at the office.

[lukasjuhrich]

Subtasks:

• Add design document describing three phases of archiving (scrubbing, freezing, deleting)
• Implement more privacy-oriented unix account tombstoning with hashed login values
• Implement && test phase 1 (data scrubbing)
• Implement && test phase 2 (freezing)
• Implement && test phase 3 (deleting)

The last thing should be trivial as it should just delete users having the deleted flag: in phase 2 a „deleted“ membership should be added proactively.