Data Protection in Shifty
Data Protection in Shifty
Type: Explanation
Audience: Admins and Developers
Related: docs/knowledge-base/privacy/admin-gdpr-guide.md, docs/knowledge-base/privacy/developer-compliance.md
Für Admins
GDPR-Überblick im Shifty-Kontext
Personenbezogene Daten in Shifty umfassen unter anderem:
- Stammdaten: Name, E-Mail, Telefonnummer
- Arbeitsbezogene Daten: Schichten, Verfügbarkeiten, Zeiterfassungen
- Kommunikationsdaten: Nachrichtenkontexte
- Sicherheits-/Systemdaten: Login-Aktivitäten, Session-Informationen
Nicht jedes technische Ereignis ist automatisch personenbezogen, aber viele Betriebsdaten sind personenbezogen, sobald sie einem Nutzer zugeordnet sind.
Data Retention aus Betriebssicht
Wichtige operative Beobachtungen aus dem Codebestand:
- Abgelaufene Sessions und zugehörige Refresh-Tokens werden automatisiert bereinigt.
- Password-Reset-Sessions werden nach Ablauf entfernt.
- Logs werden über einen GC-Job bereinigt.
Referenz:
- elbtalteamadmin-services/src/_utils/queues/garbage-collection/jobs/cleanup-database.ts
Compliance-Checkliste für Admins
- Ist transparent dokumentiert, welche Daten pro Prozess erhoben werden?
- Wissen Mitarbeitende, wie Auskunft/Export/Löschung angefragt werden?
- Gibt es einen reproduzierbaren Prozess zur Identitätsprüfung?
- Werden Lösch- und Aufbewahrungsfristen praktisch eingehalten?
- Werden sicherheitsrelevante Vorfälle nachvollziehbar dokumentiert?
Fallbeispiel: Löschanfrage
- Identität des Antragstellers bestätigen.
- Prüfen, welche Daten rechtlich aufbewahrt werden müssen.
- Lösch-/Sperrprozess im System ausführen.
- Ergebnis dokumentieren und Rückmeldung geben.
Weitere Details:
- docs/knowledge-base/privacy/admin-gdpr-guide.md
For Developers
User data categories in this codebase
Typical user-related domains include:
- identity and profile data
- team memberships and roles
- schedule-related data (events, shifts, availabilities, assignments)
- time tracking and employment-related records
- logs and auth/session metadata
Data Retention
Implemented retention behavior (verified):
- Sessions older than one month are removed.
- Refresh tokens linked to expired sessions are removed.
- Expired reset-password sessions are removed.
- Logs older than one month are removed.
Reference:
- elbtalteamadmin-services/src/_utils/queues/garbage-collection/jobs/cleanup-database.ts
Audit Logging
In this repository, application logs are persisted via a dedicated logs model and endpoints.
Storage model:
- title
- message
- level
- origin
- raw (JSON)
- timestamps
References:
- elbtalteamadmin-services/src/_db/logs.ts
- elbtalteamadmin-services/src/logs/create/func.ts
- elbtalteamadmin-services/src/logs/get/service.ts
- elbtalteamadmin-services/src/server.ts (logs endpoint registration)
Developer access path:
- POST /logs (developer role required for reading logs)
Note:
- This is operational logging and should be treated as compliance-relevant when user-linked actions are represented.
Data Export
Verified export-related implementation currently available:
- Employment records export endpoint is registered and exposed.
Reference:
- elbtalteamadmin-services/src/server.ts
- elbtalteamadmin-services/src/employment-records/export/service.ts
Project note:
- A generic single-endpoint GDPR export for all user domains is not clearly present as one unified flow in the inspected code. If needed, add a dedicated export orchestration endpoint plus queue job.
Soft Delete vs Hard Delete
The codebase uses both patterns depending on entity/model setup.
Soft-delete capable models are visible through paranoid mode and deletedAt usage, e.g.:
- events
- shifts
- assignments
- locations
- customers
- positions
References:
- examples under elbtalteamadmin-services/src/_db/*.ts with paranoid: true
- deletedAt in shared schema structures: elbtalteamadmin-services/src/_schemas/common.ts
Hard delete paths also exist via destroy calls for some entities and cleanup jobs.
Implication:
- Treat deletion semantics as entity-specific.
- For GDPR-critical entities, document whether soft-delete, hard-delete, or legal-retention archival is intended.
Implementation recommendations
- Keep retention periods centralized and explicit.
- Separate operational logs from privacy-audit data where needed.
- Add per-data-domain export manifests so request fulfillment is deterministic.
- Ensure PII minimization in logs (never raw secrets/passwords/tokens).
Verification Quicklist
- Für Admins section present: yes.
- For Developers section present: yes.
- Audit Logging section present: yes.
- Data Retention section present: yes.
- Data Export section present: yes.
- Soft Delete section present: yes.