SkyWin^One GDPR Implementation

Automatically anonymises personal data for inactive members. Jump history and financial transactions are kept — only identifying information is removed.

Triggered nightly at 02:00, and once on application startup.

The job does nothing unless both conditions are met:

1. Feature must be enabled. The system parameter GDPREraseInformation must be set to true.
2. Cooldown period. At least 30 days must have passed since the date stored in LastErasedPersonalInformationDate. If the parameter is absent the job runs unconditionally.

Members are considered for erasure when all of the following are true:

• Member type is not O(ther)
• Personal data has not already been erased
• Account balance is zero or not set

A candidate is skipped when any of the following apply:

• The member is the system's fixed Pax placeholder
• The member is the system's fixed Video placeholder
• The grace period has not yet elapsed since the member's last recorded activity (see below)

The grace period is read from the system parameter GDPRGracePeriod (number of days, defaults to 0 if absent). The member's latest activity date is determined by taking the most recent date across all of these sources:

Source	What is checked
Financial transactions	Latest transaction date on the member's account
Boogie registrations	Latest boogie end date
Licenses	31 December of the latest license year
Discounts	Latest discount end date
Jump records (as jumper)	Latest jump date
Jump records (debited for another)	Latest jump date where this member was charged
Load roles (pilot, instructor, etc.)	Latest date in a load role
Tandem passenger jumps	Latest jump date as tandem passenger
Member record itself	Latest modification date of the member record

The earliest permitted erasure date is the latest activity date plus the grace period in days. If no activity dates are found at all, the member is erased immediately. A member whose earliest erasure date is still in the future is skipped and reconsidered on the next run.

All of the following happens in a single operation for each erased member:

Deleted entirely:

• All personal messages
• All phone numbers
• All member history records
• All pending jump queue requests

Anonymised:

• Transaction comments containing the member's internal number are replaced with "Borttagen / Removed"

Member record — overwritten:

• First name set to "Rensad", last name set to "Information"
• Erasure date set to today
• Cleared fields: nickname, personal identity number, address, email address, occupation, comment, member list flags, credit flags, permanent credit, repack date, info-via-email flag, emergency contact, pilot/supporter/honorary/video flags, region, state, postcode, town

Linked passenger record (if any) — overwritten:

• First name set to "Rensad", last name set to "Information"
• Erasure date set to today
• Cleared fields: personal identity number, address, email address, comment, emergency contact, region, state, postcode, town, health comment, phone number

Audit log: An entry is written to the system log for each erased member.

Regardless of how many members were erased, LastErasedPersonalInformationDate is updated to today's date, resetting the 30-day cooldown.