CArtei
Die Mieter:innenverwaltung des Collegium Academicum
CArtei bündelt an einem Ort, wer bei uns wohnt, wer sich wo engagiert und welche Nachweise vorliegen. Alles rollenbasiert und datenschutzfreundlich: Jede:r sieht genau das, was die eigene Aufgabe erfordert – nicht mehr.
Was CArtei kann
Die wichtigsten Bausteine – in Alltagssprache.
Wohnen & Zimmer
Wer wohnt in welcher WG, welchem Zimmer und welchem Cluster – inklusive Ein- und Auszügen sowie Untermiete.
Profile mit Datenschutz
Jedes Mieter:innen-Profil zeigt Felder je nach Rolle – vom eigenen Profil bis zur Miet- und Finanzverwaltung.
Engagement-Abfragen
AG- und Initiativen-Engagement erfassen, Fristen im Blick behalten und pro Cluster auswerten.
Ausbildungsnachweise
Immatrikulationsbescheinigungen selbst hochladen; die Verwaltung prüft, bearbeitet und bestätigt sie.
Interne Notizen
Admin-Kommentare zu Mieter:innen, Clustern und WGs – zugriffsgeschützt und nachvollziehbar (append-only).
Lückenlos protokolliert
Jede Änderung wird auf Datenbankebene automatisch mit Zeitpunkt und Urheber:in im Audit-Trail festgehalten.
Unter der Haube
Für die Technikbegeisterten: aufklappen und mitlesen.
Architektur: drei Repositories Aufbau
CArtei ist bewusst in drei eigenständige Repositories geteilt, die nebeneinander entwickelt werden – klare Zuständigkeiten, sauber trennbar.
| Repo | Rolle |
|---|---|
cartei_db | Schema – die Single Source of Truth. SQLAlchemy-2.0-Modelle + Alembic-Migrationen, als Paket veröffentlicht. |
CArtei | Django-5-Webanwendung mit LDAP-Login. Liest und schreibt die Datenbank über managed=False-Spiegelmodelle. |
cartei_deployment | Podman Compose + systemd auf zwei VMs (DB + App), Backups und Bootstrap-Skripte. |
Technologie-Stack Stack
- Sprache & Tooling: Python 3.14, Paket- und Task-Runner
uv(kein barepip). - Datenbank: PostgreSQL mit SQLAlchemy 2.0 (declarative,
Mapped[...]) und Alembic-Migrationen. - Web: Django 5, Server-side-Templates, Bulma + hauseigenes CA-Design.
- Auth: LDAP gegen FreeIPA, TLS-verifiziert über den mitgelieferten CA-Cert.
- Betrieb: Podman-Container, systemd, verschlüsselte Offsite-Backups.
- Qualität: pytest in jedem Repo, CI baut und pusht die Container-Images.
Ein Schema, überall gespiegelt Datenmodell
Das Datenmodell existiert nur an einer Stelle: in cartei_db.
Eine Schema-Änderung ist immer ein zweistufiger Schritt – Modell + Alembic-Migration
in cartei_db, danach das gespiegelte managed=False-Modell in Django.
Django besitzt hier keine Domänen-Tabellen: manage.py migrate verwaltet
ausschließlich Auth, Sessions und ContentTypes. Fremdschlüssel-Constraints gehören der
Datenbank, nicht dem Framework.
Rollenbasierter Zugriff bis auf Feldebene Zugriff
Sichtbarkeit und Editierbarkeit werden pro Feld aufgelöst (~19 Felder) – anhand der LDAP-Gruppen der angemeldeten Person. Kollidieren mehrere Rollen, greift eine klare Vorrang-Regel.
Views sind mit @login_required und einem @require_group(...)-Decorator
abgesichert; das Profilformular zeigt exakt die Felder, die man bearbeiten darf. Eine
schreibgeschützte Berechtigungsmatrix macht sichtbar, wer was sehen kann.
Audit-Trail auf Datenbankebene Audit
Jede Änderung wird per PostgreSQL-Trigger nach audit_history geschrieben –
unabhängig davon, wie die Zeile geändert wurde (Django-ORM, rohes SQL,
Migration). Die Datenbank selbst hält es fest.
Die handelnde Person wird pro Request über eine Middleware / Contextvar gesetzt, sodass jeder Eintrag der angemeldeten Nutzer:in zugeordnet ist. Datumsangaben laufen durchgängig im ISO-Format (YMD).
Betrieb & Deployment Ops
Zwei getrennte VMs (Datenbank + App), betrieben mit Podman Compose. systemd-Oneshot-Services
wrappen podman compose up/down; .timer-Units treiben nächtliches
Image-Update und Backup.
Verschlüsselte Offsite-Backups landen bucket-scoped bei Cloudflare R2 (per rclone). Der
Deploy läuft über curl | bash-Bootstrap-Skripte; ein operations.md-Runbook
dokumentiert den Betrieb.
Roadmap & Status
Wo wir stehen – und was als Nächstes kommt.
✅ Bereits gebaut & im Einsatz
Datenbank-Fundament cartei_db
Ein zentrales Schema (Building, WG, Room, Tenant, AGAbfrage, EnrollmentProof, InternalNote …), SQLAlchemy 2.0 + Alembic, plus vollständiges Auditing über Postgres-Trigger.
Web-App-Kern CArtei
Django 5 mit LDAP-Login, managed=False-Spiegelmodellen, CA-Design und CI.
Inklusive Dashboard, Engagement-Abfragen und Cluster-Auswertung.
Profile & rollenbasierter Zugriff
Feld-Zugriffsmatrix (~19 Felder), rollen-getrimmtes Profilformular, editierbare Zimmerzuordnung, Untermiete und eine Berechtigungsmatrix für Admins.
Interne Notizen
Polymorphe internal_note-Tabelle mit LDAP-geschütztem Zugriff, append-only
und Soft-Delete – angezeigt auf der Profilseite.
Ausbildungsnachweise
Self-Service-Upload durch Mieter:innen, Prüfung und Bearbeitung durch die Verwaltung, automatische Berechnung des Gültigkeitsendes (31.3. / 30.9.).
Deployment & Betrieb live in Produktion
Zwei-VM-Setup mit Podman & systemd, verschlüsselte Offsite-Backups und ein dokumentiertes Runbook. Die aktuellen Builds laufen produktiv.
⬜ Backlog – geplant
Nachweis-Automatisierung & MV-Tooling NC 21 · XXL
Nächtliche Auto-Prüfung von Nachweisen (PDF-Text bzw. Vision-Modell), Alarm bei nicht lesbaren Dokumenten und ein eigenes Nachweise-Dashboard.
Briefkastenabfrage → CArtei NC 8 · L
Die Briefkasten-Umfrage als Abfrage-Workflow abbilden; die Felder auf Tenant
existieren bereits.
Soli-Miete: Verwaltung + Min/Max NC spec 5 · M
Management-Oberfläche und eine CHECK-Grenze, sobald die Limits feststehen.
Reporting & Statistiken NC spec 13 · XL
Ein Reports-Bereich für Nachweise, Engagement-Statistiken und Point-in-Time-History (die Audit-Daten liegen bereits vor, es fehlt der Viewer).
Benachrichtigungen spec 8 · L
E-Mail-Erinnerungen für Engagement-Fristen und ablaufende Nachweise.
Notizen an Clustern & WGs spec 5 · M
Das internal_note-Schema unterstützt diese Subjekte bereits – es fehlt nur die UI.
Dashboard-Extras spec 5 · M
Mehrere gleichzeitig offene Abfragen und ein modulares Widget-Grid.
Miet-/Nebenkostenabrechnung spec 21 · XXL
RoomRent (temporal) + Nebenkostenabrechnung in cartei_db;
schaltet die Finanzierung-Rolle und den Zahlungsbereich frei.
Einzugs-/Auszugs-Workflow spec 13 · XL
Onboarding und Offboarding von Mieter:innen als geführter Ablauf.
Raum-Management-UI spec 8 · L
Gebäude, WGs und Zimmer selbst verwalten – nicht nur deren Zuordnung.
Bewerberportal NC TBD · ≥13
Bewerber:innen haben die Verschwiegenheitserklärung noch nicht unterschrieben – die Voraussetzung, um aus LDAP nach CArtei geladen zu werden. Braucht einen eigenen Datensatz-Typ, der nicht an LDAP gekoppelt ist.
Priorisierung ist ein Vorschlag – umsortierbar, wie das Team es sieht. Schätzungen sind grobe Story Points (Fibonacci), Stand 14.08.2026.