Variante ohne VereinOnline (V2)

Teil des WJ-Kreis-Digital-Standards. Stand: 2026-08-14.

Achtung, ehrliche Einordnung vorab: Die Referenz-Installation WJ Konstanz-Hegau nutzt VereinOnline produktiv. Diese Variante ist NICHT als Ganzes produktiv erprobt, sondern aus denselben, einzeln verifizierten Bausteinen (Nextcloud-Apps, n8n-Muster, Talk-Kanal, Formular-Backends) konstruiert. Wo ein Baustein in der Referenz nicht verifiziert ist, steht das dabei.

1. Wann diese Variante die richtige ist

Die Kapitel 01 bis 07 beschreiben das Zielbild mit VereinOnline (VO) als System of Record. Nicht jeder Kreis kann oder will das so fahren. Diese Variante ist für zwei Situationen gedacht:

1. Kein VO-Vertrag. Euer Kreis hat (noch) kein VereinOnline, etwa in der Gründungsphase, oder ihr habt euch bewusst dagegen entschieden.
2. VO ohne API-Zugang. VO existiert als Verbands-Pflichtsystem, aber ihr bekommt keinen API-Zugang, keine Service-User oder keine Basiskonfig-Änderungen (Kapitel 04, Abschnitt 3.3). Dann ist VO für die Automatisierung faktisch nicht vorhanden; ihr pflegt dort weiter das Pflichtminimum von Hand, und euer Arbeitssystem läuft daneben.

In beiden Fällen ändert sich genau eine Sache, aber die grundlegend: die Architektur-Regel aus Kapitel 01.

V1 (mit VO): VereinOnline ist das System of Record. Nextcloud ist Dateien, Identität und Talk. n8n ist der Kurier dazwischen.

V2 (ohne VO): Nextcloud ist das System of Record UND Dateien, Identität und Talk. n8n bleibt der Kurier, jetzt zwischen Website, Nextcloud und Team.

Alles andere bleibt stehen: der Server (Kapitel über die Grundprovisionierung), die Nextcloud-Basis mit Gruppenordnern und Rechte-Matrix (Kapitel 02), Office und Talk (Kapitel 03), die n8n-Betriebs-Basics (Kapitel 05), Betrieb und Sicherheit (Kapitel 06). Kapitel 04 (VO-Anbindung) entfällt in dieser Variante komplett; seine Sicherheits-Denkweise (Service-User, Least Privilege, Verifikations-Schritte) gilt sinngemäß weiter, nur eben gegen die Nextcloud-APIs.

Die Prüffrage aus Kapitel 01 ändert sich mit: "Welches System hält danach die Daten?" hat in V2 nur eine richtige Antwort, nämlich Nextcloud. Eine Excel-Schattenliste ist in V2 genauso falsch wie in V1.

Und weil die Frage kommen wird: Warum nicht einfach eine Datenbank oder ein Vereins-Tool XY dazustellen? Weil jedes zusätzliche System einen zweiten Ort für Personendaten, einen zweiten Login und einen zweiten Betriebsaufwand bedeutet. Der Punkt dieser Variante ist, mit dem auszukommen, was die Nextcloud ohnehin mitbringt. Erst wenn das nachweislich nicht mehr reicht, kommt ein Fachsystem dazu, und das ist dann sinnvollerweise VO (Abschnitt 5).

2. Mitgliederverwaltung in Nextcloud

2.1 Zwei Verzeichnisse, klar getrennt

In V2 gibt es zwei Arten von Personen-Verzeichnissen in derselben Nextcloud, und die Trennung ist der wichtigste Ordnungsgedanke dieses Abschnitts:

1. Die Kontakte-App ist das Mitgliederverzeichnis (das eigentliche System of Record für Personen). Hier steht jede Person, die zum Kreis gehört, unabhängig davon, ob sie einen Login hat.
2. Benutzerkonten sind Arbeitszugänge. Ein NC-Account bekommt, wer im Arbeitsraum mitarbeitet (aktive Mitglieder, Vorstand). Interessenten und Fördermitglieder haben in der Regel keinen Account, stehen aber im Verzeichnis.

Wer wissen will, wer zum Kreis gehört, schaut in die Kontakte-App. Wer wissen will, wer worauf Zugriff hat, schaut in die Gruppen. Beides kann auseinanderlaufen (ein Fördermitglied ohne Login, ein technischer Bot-Account ohne Mitgliedschaft), und genau deshalb sind es zwei Verzeichnisse.

2.2 Adressbücher als Bestandsgliederung

Legt in der Kontakte-App getrennte Adressbücher an, mindestens diese drei:

Adressbücher lassen sich in Nextcloud gezielt teilen; so bildet ihr ab, dass nicht jedes Mitglied jede Interessenten-Mail sehen muss. Der Lebenszyklus einer Person ist in V2 schlicht ein Umzug zwischen Adressbüchern: Interessent wird Mitglied (Karte wandert von Interessenten nach Mitglieder), Mitglied wird mit 40 Alumni (Karte wandert nach Foerderer).

Für die Felder gilt: Die Kontakte-App speichert vCards, und die Automatisierung (Abschnitt 4) hängt an einzelnen Feldern. Definiert deshalb eine kleine Feld-Konvention und haltet sie ein:

• Geburtstag ins Standard-Geburtstagsfeld (vCard BDAY), sonst gibt es keinen Geburtstags-Digest.
• Aufnahmedatum in ein festes Zusatzfeld (die Kontakte-App erlaubt eigene Felder), immer ISO 8601 (YYYY-MM-DD), sonst gibt es keine Jubiläen. Dokumentiert den exakten Feldnamen eures Kreises an einer Stelle, denn der Parser des Kuriers muss ihn kennen.
• E-Mail ist der Match-Schlüssel für alle Automatisierungen (Anmeldung, Radar). Eine Person, eine primäre Adresse.

2.3 Gruppen bleiben die Rechte-Träger

An Kapitel 02 ändert sich nichts: NC-Benutzergruppen (Vorstand, Finanzen, Ressorts, Aktive_Mitglieder usw.) tragen die Rechte an den Gruppenordnern, an Talk-Räumen und an geteilten Kalendern. Neu ist in V2 nur die Pflegerichtung: In V1 sollten die Gruppen perspektivisch den VO-Rollen folgen (Kern-Flow), in V2 werden sie direkt gepflegt, von Hand oder per Amtsübergabe-Flow (Abschnitt 4, Flow 12). Die Kontakte-App vergibt keine Rechte; Kontaktgruppen dort sind Etiketten fürs Verzeichnis, keine Berechtigungen. Verwechselt die beiden nicht.

2.4 Gäste-App für Externe

Auch das bleibt wie in Kapitel 02, Abschnitt 7: Externe, die über längere Zeit an konkreten Dateien mitarbeiten (Projektpartner, Agentur, Landesverband), bekommen einen Gast-Account über die Guests-App, sehen nur explizit Geteiltes und tauchen in keiner Zeile der Rechte-Matrix auf. Interessenten und Fördermitglieder sind keine Gäste; wenn sie Zugriff brauchen, bekommen sie eigene Gruppen mit gezieltem Leserecht.

2.5 Was Nextcloud ehrlich NICHT kann

Damit niemand mit falschen Erwartungen startet, die harten Lücken gegenüber VO:

• Kein Beitragswesen. Keine Beitragssätze, keine SEPA-Lastschriften, keine Rechnungen, keine Mahnläufe. Das bleibt Handarbeit (Banking plus eine Tabelle im Finanzen-Gruppenordner) oder ein Fremdsystem der Schatzmeisterei. Plant das von Anfang an ein; es ist der häufigste Grund, warum Kreise später doch zu VO (zurück)gehen.
• Keine Verbandsmeldung. Mitgliederzahlen und Meldungen an Landesverband und WJD erzeugt euch niemand automatisch. In V2 heißt das: Export aus der Kontakte-App (vCard/CSV) plus Handarbeit, oder ihr pflegt das Pflichtminimum weiter im Verbands-VO (Situation 2 aus Abschnitt 1).
• Keine Mitglieder-Selbstverwaltung. In VO können Mitglieder ihr eigenes Profil pflegen. Ein geteiltes Adressbuch mit Schreibrecht für alle wäre das Gegenteil von Datenqualität; lasst die Pflege bei einer definierten Rolle (Mitgliederwesen) und meldet Änderungen per Formular.
• Kein Double-Opt-In frei Haus. In V1 verschickt VO die Bestätigungsmail für Interessenten und Newsletter selbst. In V2 müsst ihr Einwilligungen selbst sauber einholen und dokumentieren (Formular mit Consent-Checkbox, Bestätigungs-Mail über den Kurier, Nachweis in der Kontaktkarte). Das ist machbar, aber es ist eure Verantwortung, nicht die eines Herstellers.

3. Events ohne VereinOnline

Drei Nextcloud-Apps übernehmen zusammen, was in V1 die VO-Eventverwaltung war:

Der NC-Kalender ist die Event-Quelle. Ein geteilter Kreis-Kalender (Empfehlung: WJ Events für öffentliche Events, optional ein zweiter für interne Sitzungen) ist der einzige Ort, an dem Events angelegt werden. Was nicht im Kalender steht, existiert nicht; das ist die V2-Fassung von "VO ist einzige Event-Wahrheit". Schreibrecht auf den Kalender haben die Rollen, die Events anlegen (Events-Ressort, Vorstand), alle anderen abonnieren ihn lesend. Technisch ist der Kalender per CalDAV erreichbar (remote.php/dav/calendars/...), und genau dort pollt der Kurier (Abschnitt 4).

Forms nimmt Anmeldungen entgegen. Pro Event mit Anmeldung ein Formular (Nextcloud Forms oder ein n8n-Formular wie beim Lead-Funnel aus Kapitel 05), der öffentliche Link dazu gehört in die Beschreibung des Kalender-Events und auf die Website. Die Antworten sind eure Teilnehmerliste. Konvention: Der Formular-Link steht IM Kalender-Event, damit Automatisierungen (Reminder, Ankündigung) ihn von dort mitnehmen können. Ehrlicher Hinweis: Ob und wie sich Forms-Antworten maschinell abholen lassen (Forms-API), ist auf der Referenz-Installation nicht verifiziert; verlasst euch beim Bau zuerst auf n8n-eigene Formulare mit Webhook-Charakter, die in der Referenz produktiv laufen, und verprobt die Forms-API separat, bevor ein Flow davon abhängt.

Deck trägt die Orga. Pro größerem Event ein Deck-Board (oder eine Karte auf dem Jahres-Board des Events-Ressorts) mit den Orga-Aufgaben: Location, Sponsoren, Technik, Kommunikation. Deck ersetzt keine Anmeldeliste und keinen Kalender, es ist das Arbeitswerkzeug dahinter.

Gegenüber V1 verliert ihr: Anmeldungen direkt am Mitglieder-Datensatz (in V2 ist die Teilnehmerliste eine Formular-Antwortliste, der Abgleich mit dem Mitgliederverzeichnis läuft über die E-Mail), Warteliste und Teilnehmerlimits aus VO (in V2 Handarbeit oder Formular-Logik) und die VO-Anmeldemaske für eingeloggte Mitglieder. Gewonnen wird: ein Kalender, den jedes Gerät der Mitglieder nativ abonnieren kann, und Formulare, die ihr vollständig selbst gestaltet.

4. Flow-Katalog-Mapping: alle 20 Flows in V2

Der Flow-Katalog aus Kapitel 05 bleibt die Ziel-Liste, aber jede VO-Quelle braucht einen Ersatz. Drei Kategorien:

• identisch: Der Flow hat keine VO-Abhängigkeit und läuft unverändert.
• NC-Quelle: Der Flow bleibt, aber Quelle bzw. Ziel wechseln von der VO-API auf eine Nextcloud-Schnittstelle. Da weder VO noch Nextcloud-Kalender/Kontakte Push-Trigger für n8n liefern, bleibt das Trigger-Muster gleich: Schedule plus Poll plus Diff (Kapitel 05), nur die gepollte API ist jetzt CalDAV, CardDAV, OCS oder die Antwortliste eines Formulars.
• entfällt: Der Flow ist in V2 gegenstandslos.

Was die Tabelle nicht zeigen kann, in Prosa:

Flow 1 entfällt, und das ist die größte Entlastung der Variante. Der strategisch wichtigste und teuerste Flow des V1-Katalogs (2 bis 4 Tage plus Offboarding-Regime) existiert in V2 nicht, weil es keine zweite Wahrheit gibt, die synchron gehalten werden müsste. Onboarding heißt in V2: Kontaktkarte anlegen, NC-Account anlegen (von Hand oder per kleinem Skript über die OCS-API), Gruppen setzen, Welcome-Mail. Offboarding heißt: Account deaktivieren (nie löschen, wie in V1), Gruppen entziehen, Karte nach Foerderer oder ins Archiv-Adressbuch verschieben. Dieselbe DSGVO-Sorgfalt wie beim V1-Offboarding gilt weiter, nur ohne Diff-Automatik: Nehmt den Punkt in eine Quartals-Routine (passt zum Datenpflege-Reminder, Flow 11).

Die Event-Flows (4, 8, 9, 13, 16, 19) sind die dankbarsten Umbauten. Sie tauschen exakt einen Node: statt ?api=GetEvents ein CalDAV-Request auf den Kreis-Kalender. Die komplette V1-Fallensammlung zu GetEvents (zeit stunde-only, anzahltage fehlend, freieplaetze als String, Kapitel 04, Abschnitt 3.5) entfällt ersatzlos, dafür kommen die iCal-Klassiker: Zeitzonen und Serientermine (RRULE) muss der Parser korrekt expandieren, sonst feuert der Reminder für die Stammtisch-Serie nur beim ersten Termin. Das ist als Richtwert formuliert; ein produktiv verprobter CalDAV-Parser existiert auf der Referenz-Installation nicht. Titel-Blacklist (Foto-Drop) und Titel-Whitelist (Protokoll-Pipeline) funktionieren unverändert, alternativ trennt ihr in V2 sauberer über zwei Kalender (Events vs. Sitzungen) statt über Titel-Regex.

Die Mitglieder-Flows (5, 7, 11, 14, 15) hängen an der Feld-Konvention. Jubiläen gibt es nur, wenn das Aufnahmedatum als Zusatzfeld gepflegt ist (Abschnitt 2.2); der Datenpflege-Reminder (Flow 11) wird dadurch in V2 noch wichtiger als in V1, denn es gibt keinen VO-Datensatz als zweite Chance. Der Kurier braucht dafür Leserecht auf die Adressbücher: Teilt sie an den Bot-User (wj-bot-Muster aus Kapitel 05), der damit weiterhin bewusst wenig darf, nur eben zusätzlich Kontakte lesen. Für Flows, die Kontakte SCHREIBEN (3, 15), gilt das V1-Prinzip der getrennten Zugänge sinngemäß: eigenes App-Token, und der Schreibpfad wird wie in V1 zuerst im Dry-Run gefahren.

Die Anmelde-Kette (2, 18, 20) wird in V2 paradoxerweise verlässlicher. In V1 hingen Gast-Radar und Aktivierungs-Score an einem unverifizierten VO-Endpoint für Teilnehmerlisten. In V2 laufen alle Anmeldungen durch euer eigenes Formular-Backend (Flow 2), die Historie liegt also vollständig in eurer Hand (Data-Table oder CSV im Vorstands-Gruppenordner). Der Preis: Flow 2 muss von Tag 1 an sauber ablegen, denn diese Ablage ist jetzt die einzige Teilnehmer-Wahrheit. Der Verifikations-Schritt gegen den VO-Anonym-Fallback entfällt; an seine Stelle tritt die Prüfung, dass der WebDAV-Write wirklich gelandet ist (Statuscode prüfen, nie blind 200 melden).

Flow 3 verliert das geschenkte Double-Opt-In. VO verschickte die Bestätigungsmail selbst; in V2 baut ihr den Bestätigungsschritt in den Kurier (Mail mit Bestätigungslink auf einen zweiten Webhook, erst der Klick legt die Kontaktkarte endgültig an) oder ihr dokumentiert die Einwilligung aus dem Formular-Consent sauber in der Kontaktkarte. Gleiches gilt für die Newsletter-Variante des Flows. Ohne einen dieser beiden Wege ist der Flow nicht fertig.

Flow 12 wird einfacher und ehrlicher. In V1 war die Quelle das VO-Rollenfeld, das erst jemand pflegen muss. In V2 gibt die Kreissprecherin die Amtswechsel direkt in ein n8n-Formular ein, der Flow zeigt den Diff zur Bestätigung und zieht dann die NC-Gruppen um. Human-in-the-Loop bleibt Pflicht wie in Kapitel 05.

5. Migrationspfad: erst NC-only, später VO andocken

Die Variante ist kein Gegenentwurf, sondern eine Ausbaustufe. Der empfohlene Weg für einen Kreis, der bei null startet:

Phase A, NC-only (diese Variante). Server, Nextcloud-Basis, Talk, Adressbücher, Kreis-Kalender, die identischen Flows (6, 10) und die dankbaren Event-Flows (4, 8, 9). Damit läuft ein kompletter Kreis-Alltag. Haltet euch von Anfang an an zwei Disziplinen, die später die Migration tragen: die Feld-Konvention aus 2.2 (vor allem E-Mail als Schlüssel, Daten ISO 8601) und die Regel "ein Verzeichnis, keine Schattenlisten".

Phase B, VO kommt dazu. Sobald Beitragswesen oder Verbandspflichten VO erzwingen (oder der API-Zugang doch bewilligt wird), dockt ihr VO an, und die Architektur-Regel klappt zurück auf V1: VO wird System of Record für Mitglieder und Events, Nextcloud gibt diese Rolle ab. Das ist ein bewusster Schnitt an einem Stichtag, kein schleichender Übergang. Es zieht um:

1. Mitglieder-Stammdaten: Export aus der Kontakte-App (vCard/CSV), Import in VO, danach Stichproben-Abgleich (Anzahl, E-Mail-Duplikate, Umlaute; die Encoding-Falle aus Kapitel 04, Abschnitt 3.4 gilt schon beim Import). Die Adressbücher werden danach zum read-only Spiegel degradiert oder abgeschafft; auf keinen Fall werden sie weiter parallel gepflegt.
2. Events: Künftige Events werden in VO angelegt, der NC-Kreis-Kalender wird zum Anzeige-Spiegel (per Flow aus VO befüllt) oder abgelöst. Laufende Anmeldelisten des alten Modells werden abgeschlossen, nicht migriert.
3. Flows: Jeder NC-Quelle-Flow aus der Tabelle wandert auf seine V1-Fassung zurück (CalDAV/CardDAV-Node raus, VO-Node rein). Da das Trigger-Muster (Schedule, Poll, Diff, Dedup) identisch ist, ist das pro Flow ein kleiner Eingriff, kein Neubau. Ab jetzt gelten wieder alle VO-Fallen aus Kapitel 04, inklusive Service-User-Konzept und Anonym-Fallback-Verifikation.
4. Neu hinzu kommt Flow 1 (Mitglieder-Sync VO zu NC), denn ab Phase B gibt es wieder zwei Systeme, die synchron bleiben müssen. Sein Dry-Run-Regime aus Kapitel 05 gilt vollständig.

Was NICHT umzieht: Dateien, Gruppenordner, Rechte-Matrix, Talk, Office, Gäste, die identischen Flows. Der gesamte Arbeitsraum bleibt unberührt; genau deshalb ist NC-only ein sicherer Startpunkt und keine Sackgasse.

Warnung vor der Doppel-Phase. Das größte Migrationsrisiko ist die Zeit, in der beide Systeme "ein bisschen" gepflegt werden. Legt den Stichtag fest, kommuniziert ihn, und macht die Adressbücher am Stichtag technisch read-only (Share-Rechte entziehen). Eine Woche Doppel-Pflege erzeugt mehr Datenschäden als die ganze Migration.

Checkliste

Mechanisch abhakbar für einen V2-Kreis:

• Entscheidung dokumentiert, warum V2 (kein VO-Vertrag oder VO ohne API-Zugang) und wann sie überprüft wird (Empfehlung: jährlich zur Mitgliederversammlung).
• Adressbücher Mitglieder, Interessenten, Foerderer angelegt, Share-Rechte rollenbasiert vergeben, Pflege-Rolle benannt.
• Feld-Konvention schriftlich: Geburtstag in BDAY, Aufnahmedatum als benanntes Zusatzfeld in ISO 8601, E-Mail als Match-Schlüssel.
• NC-Benutzergruppen tragen die Rechte (wie Kapitel 02); Kontaktgruppen der Kontakte-App vergeben KEINE Rechte, und das ist dem Team bekannt.
• Kreis-Kalender als einzige Event-Quelle angelegt, Schreibrecht nur für definierte Rollen, Abo-Link ans Team verteilt.
• Pro Anmelde-Event ein Formular, Link im Kalender-Event; Anmeldungen landen automatisch in genau einer Ablage (Data-Table oder CSV im Gruppenordner), nicht in Postfächern.
• Beitragswesen und Verbandsmeldung als Handarbeit einem Amt zugeordnet (Schatzmeisterei/Mitgliederwesen), Verfahren dokumentiert.
• Einwilligungen (Interessenten, Newsletter) mit eigenem Double-Opt-In oder dokumentiertem Consent, da VO diese Arbeit nicht mehr übernimmt.
• Bot-User hat Leserecht nur auf die benötigten Adressbücher und Kalender; Schreibpfade laufen über getrennte Token und starten im Dry-Run.
• CalDAV-Parser gegen Serientermine (RRULE) und Zeitzonen getestet, bevor ein Event-Flow aktiv wird.
• Kein zweites Personen-Verzeichnis in Betrieb (keine Excel-Schattenliste, kein zusätzliches Tool).
• Offboarding-Routine (Account deaktivieren, Gruppen entziehen, Karte verschieben) beschrieben und in einer Quartals-Routine verankert.
• Migrationspfad zu V1 gelesen; Stichtags-Prinzip und Read-only-Schaltung der Adressbücher sind dem Vorstand bekannt.

Referenz KNH

Ehrlicher als sonst: Für dieses Kapitel gibt es KEINE produktive Referenz. WJ Konstanz-Hegau fährt V1 mit VereinOnline als System of Record; kein Kreis betreibt diese V2-Variante heute nachweislich im Ganzen. Was aus der Referenz-Installation trotzdem belastbar einfließt:

• Alle Nextcloud-Bausteine sind dort produktiv oder installiert: Kontakte 8.7.6, Kalender 6.5.3, Forms, Polls, Deck, Guests (Bestandsaufnahme 2026-08-13, meta/inventory-live.md), dazu Gruppenordner und Rechte-Matrix aus Kapitel 02.
• Die beiden identisch-Flows (Foto-Drop manuell, Lead-Formular) laufen produktiv ohne jede VO-Abhängigkeit und sind damit auch für V2 verifiziert.
• Das Trigger-Muster Schedule/Poll/Diff/Dedup, das Bot-User-Konzept, das Formular-Hardening (CORS, Validierung, Honeypot) und der Talk-plus-wa.me-Kanal sind in der Referenz erprobt und werden hier nur auf andere Quellen gerichtet.
• NICHT verifiziert sind: ein produktiver CalDAV/CardDAV-Parser im Kurier, der maschinelle Zugriff auf Forms-Antworten und das Double-Opt-In über den Kurier. Diese drei Punkte sind als Richtwert bzw. Bauauftrag formuliert; wer diese Variante als erster Kreis produktiv fährt, sollte seine Erkenntnisse in dieses Kapitel zurückspielen.

Die Demo-Instanz für WJ Hochrhein (wjhcloud.wjknh.de, nur Testdaten) ist der natürliche Ort, um diese Variante gefahrlos durchzuspielen, bevor ein Kreis sie mit echten Daten startet.