Stand v0.21.3 (Juli 2026) · Kein Addon — fixer Core-Bereich · Konzept: docs/konzept-datei-browser.md · App apps/assets
Die zentrale Dateiablage des Vereins: eine Quelle für Vereinsdokumente, Webseiten-Bilder, Rechnungs-Logos und (seit v0.23) Buchhaltungs-Belege — mit Ordner-Berechtigungen, Papierkorb und Lösch-Schutz.
Im CluCore (/clucore/dateien/):
- Ordnerbaum mit Unterordnern, Liste/Galerie-Ansicht, Mehrfach-Upload, Umbenennen, Verschieben, Meta-Panel (wer, wann, Typ, Grösse).
- Thumbnails und Inline-Vorschau für Bilder und PDF.
- Papierkorb statt Hartlöschen: Gelöschtes bleibt 30 Tage wiederherstellbar (Cron räumt täglich 05:20 auf).
- Öffentliche Ordner (nur CluCore schaltbar): Dateien darin sind ohne Login unter einer stabilen URL erreichbar (
/public/<id>/<name>, Kopier-Button mit ✓-Feedback) — der bewusste Weg, um z.B. Statuten oder Formulare auf der Webseite zu verlinken.
- Berechtigungen pro Ordner in drei Stufen (Lesen · Lesen+Schreiben · +Löschen) an Personen, Gruppen, Mitgliedschaften oder «alle im Verein»; Unterordner erben, bis sie eigene Einträge haben (Statuszeile zeigt, woher die Rechte kommen).
- Speicher-Anzeige «x von 2 GB» pro Verein.
Im Clu-Portal: Kachel «📁 Dateien» — Mitglieder sehen genau die Ordner, für die sie (direkt oder via Gruppe/Mitgliedschaft) freigeschaltet sind, und dürfen je nach Stufe hochladen oder löschen. Die Kachel selbst wird pro Rolle freigegeben (portal.dateien); die Standard-Mitglied-Rolle hat sie bewusst NICHT.
Integrationen: Webseiten-Builder-Button «📁 Aus Vereins-Dateien wählen» (Bilder aus öffentlichen Ordnern), Faktura-Konto-Logo, Buchhaltungs-Belege. Alle Verwendungen landen in einer Registry → Lösch-Schutz: Eine verwendete Datei lässt sich nicht löschen, der Hinweis sagt WO sie verwendet wird («Webseite ‚Über uns'», «Rechnungs-Konto ‚Vereinskonto'», «Buchung 2026-00042»).
¶ Warum so gebaut — und warum nicht anders
- Eigenbau statt Nextcloud/Cloud-Drive-Anbindung: Der Wert liegt in der Integration — Berechtigungen auf Vereins-Entitäten (Gruppe, Mitgliedschaft!), Lösch-Schutz über die Verwendungs-Registry, kein zweites Login, ein Design. Ein externes Tool könnte nichts davon.
- Lokaler Storage statt S3 ab Tag 1: Bei der aktuellen Grösse wäre S3 Kosten/Komplexität ohne Nutzen. Dafür gilt die Storage-Leitplanke: sämtlicher Dateizugriff läuft strikt über Djangos Storage-API (nie direkte Pfade) — der Wechsel auf S3-kompatiblen Object Storage (ab ~50–100 aktiven Vereinen oder >100 GB) ist dann Config + Datei-Kopie, keine Code-Änderung.
- Rechte werden zur LAUFZEIT aufgelöst (wie beim Kalender), nicht materialisiert: Ein Gruppenbeitritt wirkt sofort, es gibt keine Sync-Jobs, die auseinanderlaufen können. Vererbung: der NÄCHSTE Vorfahre mit eigenen Einträgen entscheidet; ganz ohne Einträge ist ein Ordner im Portal ZU (Datenschutz-Default), im CluCore immer sichtbar.
- Papierkorb zählt zum Quota — sonst wäre das Limit über den Papierkorb umgehbar. Wiederherstellen darf, wer im Quell-Ordner Löschrecht hat; endgültig leeren nur CluCore.
- Keine externen Share-Links (User-Entscheid): Links mit Token wandern unkontrolliert weiter. Öffentliche Ordner sind das transparente Gegenmodell — man sieht im Baum genau, was öffentlich ist, und beim Löschen öffentlicher Dateien warnt das System extra.
- SVG/HTML nie inline (immer Download): SVG kann Skripte enthalten — klassischer XSS-Vektor. Inline nur Raster-Bilder + PDF. Dazu 25-MB-Limit und Endungs-Blockliste (exe, sh, js …).
- Builder-Anbindung als Ein-Weg-Picker statt Zwei-Wege-Sync: Der Builder wählt Dateien aus und meldet Verwendungen zurück (interne API mit geteiltem Key) — ein echter Sync hätte Konfliktfälle (Umbenennen/Löschen auf zwei Seiten) ohne Mehrwert gebracht.
- Duplikat-Erkennung über Checksum (Hinweis statt Blockade): doppelte Uploads passieren; das System sagt es, entscheidet aber nicht für den User.
Externe Share-Links · Datei-Versionierung · Office-Vorschau · Zwei-Wege-Builder-Sync · S3-Betrieb (nur vorbereitet). Newsletter-Anbindung folgt mit dem News-Ausbau.