@mkirsch Danke. Gibt es auch die Möglichkeit zu sehen, wer sie benutzt (Name)?

Hallo @thommyb,

danke für den Semantik-Hinweis „split and update" - das war die Lösung. Ich bin noch neu bei ChurchTools und brauche noch ein paar Aha-Effekte, um eure Philosophie im Modell ganz zu verstehen.

Die Selbstkritik zur noch nicht vollständigen Doku nehme ich als sehr positiv und ehrlich wahr. Gleichzeitig seid ihr, was die Automatisierungsmöglichkeiten angeht, sehr vorbildlich und weit und habt die richtigen Weichen gestellt. Dass da immer wieder ein paar Swagger-Einträge fehlen (und immer wieder fehlen werden), ist ein Zeichen für Weiterentwicklung, nicht für Stillstand.

Für alle, die das später über die Suche finden, hier der komplette Weg, da der Endpoint aktuell nicht in der OpenAPI-Spec auftaucht:

Endpoint: POST /api/calendars/{calendarId}/appointments/{appointmentId} - also POST auf den Serien-Termin selbst (die Spec kennt auf diesem Pfad nur GET/PUT/DELETE).

Body: die Felder des herausgelösten Einzeltermins plus die Split-Parameter - analog zum dokumentierten Booking-Split (POST /bookings/{bookingId}):

{ ... "title": "…", "startDate": "2026-08-19T18:00:00Z", "endDate": "2026-08-19T19:00:00Z", "allDay": false, "description": "…", "isInternal": false, "repeatId": 0, "appointmentId": 108879, "splitDate": "2026-08-19", "splitUntilEnd": false ... }

Verifiziert (bei uns): Der Server erledigt alles atomar in einem Request - Einzeltermin wird angelegt (Response enthält die neue ID), die Exception landet in der Serie, und ein am Datum hängendes Event wird samt allen eventServices (inklusive besetzter Dienste) auf den neuen Einzeltermin umgehängt. Verhalten damit identisch zu „Nur diesen Termin ändern" in der UI. Genau das, was wir gebraucht haben.

Eine kleine Anmerkung noch: Ein GET auf die Serie unmittelbar nach dem POST kann die neue Exception noch nicht enthalten (kurzer Verzug).

Danke und viele Grüße
Darijo

@BiKi Ich hatte vorher schon ein bisschen im Forum gesucht und nur Threads gefunden, welche ähnliche, aber nicht genau diesen Use-Case behandeln.

Ich habe für unsere Gemeinde daher ein eigenes Programm geschrieben...

...was du vielleicht teilen möchtest? 🙂
Ich hatte, nachdem ich das Thema hier im Forum und das Alter der Beiträge gesehen habe, auch überlegt, etwas eigenes zu schreiben. Aber wenn es da schon was gibt...

@alex-muehlbauer Das fände ich auch gut. Es braucht ja nur das Feld Empfänger mit Optionen Benutzer, Leiterrollen, freie Eingabe. So könnte man sich gut über neue Nutzer in einer Gruppe informieren lassen ohne über alle Änderungen zugespamt zu werden.

Auch für uns wäre es relevant einstellen zu können, ob ein neues Mitglied einer Gruppe den ganzen Chatverlauf bekommt oder nicht.

Dieselbe Funktion wünschen wir uns auch!

@Klausosigus @mwolff Das Feature ist bereits "In Arbeit", siehe Roadmap.

Bildschirmfoto 2026-07-18 um 22.14.41.png

@gbahr sagte in Deutliche Kennzeichnung des Simulationsmodus in Historie und Email:

@alex-muehlbauer das würde ich unterstützen!

Ich würde das auch unterstützen. Mach das so manchmal, dass ich im Namen von jemand anders die ich gerade telefoniere, eine E-Mail verschicke. Dennoch fänd ich es ganz hilfreich, wenn der mein Versand des Kennzeichens würde. Auch wenn der Begriff Simulations noch hilfreich ist, ist eine andere Frage bei Outlook zum Beispiel läuft es im im Auftrag von oder so wie sein guter Vorschlag.

@thommyb Herzlichen Dank für die Hilfe!

@hbuerger wenn du die Kalender in deinen Google Account abonnierst dann kommen sie auch in der android app

@CarstenL
Schau mal hier 🙂
https://churchtools.academy/de/help/system-einstellungen/allgemein-system-einstellungen/wie-fuelle-ich-das-widget-links-und-berechtige-nutzer-dafuer/

@alexentz Wir nutzen diverse Kalender:
Gottesdienst, Gemeindeveranstaltungen, sonstige Termine (intern), Jugend, Kinder, Frauen ….
sowie Gruppenkalender
Jugend, Kinder, Musik, Kleingruppen, Haus und Garten….
Es gibt immer zuerst einen Kalendereintrag, dazu dann das Event. Für die meisten Veranstaltungen gibt es Kalendervorlagen incl. der entsprechenden Eventvorlage und Ressourcen. Müssen keine Dienst geplant werden, gibt es auch kein Event.
Jeder Termin wird nur einmal in dem passenden Kalender eingetragen.

Durch die Vielzahl der Kalender ist eine gute Filterung und Übersicht möglich. Im Web wie auch in der App und auch für die persönliche Kalenderintegration. Nicht jeder möchte immer alle Termine angezeigt bekommen.
Die Sichtbarkeit der Kalender steuern wir über den Personenstatus und die Gruppenzugehörigkeit.
"- Nicht-eingeloggte Person -" hat auf die Kalender Zugriff, die wir öffentlich darstellen möchten.

Bei Änderungen würde das aber immer bedeuten, nicht nur an einer Stelle Anpassungen vorzunehmen, sondern an mehreren.

Welche Änderungen meinst du?

Wir möchten gerne, dass unsere User alle Infos über ChurchTools bekommen können und nicht noch in anderen Messengern sein müssen, um alles mitzubekommen. Gelegentlich nutzen wir auch Videos für Ankündigungen und Einladungen. Es wäre daher schön, wenn man Videos im Chat und in Beträgen posten könnte.

@jziegeler - Wir haben dasselbe Problem: 8 Bierzeltgarnituren, die wir als Ressourcen verwalten wollen. ChurchTools soll Mengenangaben zu Ressourcen anbieten, und bei der Buchung gibt man dann die Anzahl an, und ChurchTools soll prüfen, dass nicht zu viel angefragt wird.

Unser aktueller Workaround ist es, acht verschiedene Ressourcen anzulegen:

Bierzeltgarnitur 1 Bierzeltgarnitur 2 Bierzeltgarnitur 3 Bierzeltgarnitur 4 Bierzeltgarnitur 5 Bierzeltgarnitur 6 Bierzeltgarnitur 7 Bierzeltgarnitur 8

Das ist nicht schön. Mir wäre es lieber ChurchTools hätte die in diesem Thread angefragte Funktion. Wann wird das kommen?

Ich habe endlich einen Weg gefunden, wie das ganze doch funktioniert, wie ich will:

Man kann bei ein Event bearbeiten und einen Verantwortlichen hinterlegen:
Screenshot Änderung im Datensatz

Anschließend ist der Verantwortliche in der Lage die Dienste für den Termin anzupassen.

@philipp-hoermann Das klingt stark nach einem Bug. Die meldest du am besten immer direkt über https://contact.church.tools/bug