@bwl21 Ich glaube, die sind noch in der Closed Beta, daher wissen nicht alle, was du meinst 😉

Bin tatsächlich auch schon dabei, Chatty für eine entsprechende Lösung zu bemühen. Bin aber noch nicht zufrieden genug zum Veröffentlichen

@simons Stimmt genau, vielen Dank für den Hinweis!

@jziegeler sagte in Frage zu Rechtevergabe in Gruppen (Man soll nur sich selbst sehen):

@Andi-1 das solltest du über die sichtbarkeit der Gruppe einstellen können intern = alle eingeloggten Personen sehen diese Gruppe

Danke, aber auch das ist ja wieder etwas anderes, als "Alle Mitglieder der Gruppe A (oder der Status X ) sollen die Gruppe B ohne deren Mitglieder sehen können". Mit deinem Weg kann ich niemanden mehr ausschließen. Das müsste ich erst nochmal überlegen, ob ich das an dieser Stelle so haben möchte.

@alexentz sagte in Kalender Nutzung:

Bei der Dienstplanung finde ich es aber dann wiederum Kontraproduktiv mit mehreren Kalender zu arbeiten, da manche Teams voneinander wissen sollen bzw. am selben Event dienen. Oder ist es schon zu spät und ich denke falsch? 🤗

Teams, die von einander wissen sollen, kam man mit entsprechenden Berechtigungen zu solchem Wissen verhelfen.

Wenn es aber dasselbe Event ist, steht es doch sim selben Kalender? Oder meinst Du Event nicht im ChurchTools-Sinn wie z.B.: Gemeindefest mit morgens Gottesdienst (>GoDi-Kalender, GoDi-Dienste), Mittagessen (>allg.Kalender, Küchendienst), Nachmittagsprogramm (>all.Kalender, ...), abends Abschlußkonzert (> Musik-Kalender, >Technik-Dienst)?

@alylit sagte in Kann ich einzelne Beiträge archivieren oder deaktivieren?:

Ist es aber möglich als Admin/Gruppenleiter Beiträge von anderen zu archivieren, um eine Beitragsgruppe ordentlich zu halten?

Aktuell nicht.

@MichaelG sehe ich genauso, daher hatte ich dafür bereits ein FR erstellt 🙂

https://forum.church.tools/topic/10580/beiträge-anzeigeoption-erweitern-um-meine-gemeinde

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

@gbahr Inzwischen haben wir herausgefunden woran es liegt. Wenn sich die App bei dem Chat anmeldet, meldet sich der Chat einmal in dem ChurchTools-System per Login-Token an, um zu überprüfen, ob die Zugangsdaten auch stimmen. Dafür haben wir eine kleine Node.js-Anwendung geschrieben, die sich für den Chat in das ChurchTools-System einloggt und - wie Claude es sagt - bei dem fetch keinen User-Agent gesetzt und daher taucht das in den Logs mit browser: node auf. Es ist also nicht direkt die App, aber wird dadurch getriggert, dass sich die App im Chat einloggt.

Eine KI ist hier nicht im Einsatz und es ist auch sicherheitstechnisch keine Gefahr oder datenschutzrechtlich kein Problem, da es sich um unsere eigenen Systeme handelt.

In Zukunft sollte hier nicht mehr browser: node stehen, sondern churchtools-chat-auth, damit auch klar ist, was genau das auslöst 😉

@Roland-O Mir ist nicht bekannt, dass das möglich wäre.

Weiß das jemand von den CT-Mitarbeitern?

@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.

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

Bildschirmfoto 2026-07-18 um 22.14.41.png

@SilasGuenther perfekt, das ist hilfreich zu wissen. Dann weiß ich, mit was für einer Version meine Leute im schlimmsten Fall unterwegs sind. Hilft bei der Fehlersuche.

@gmaess Danke das ihr euch da gute Gedanken macht und direkt alles rechtlich mit bedenkt. Bei solchen Funktionen sind immer dickere Bretter zu bohren, als man es als Nutzer vermuten würde.

@Andi-1 Ja, genau das sind die Filterregeln. Bei mir sind sie halt umbenannt; klick mal auf den Stift...

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

@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!

Nicht alle, aber alle die die App auf dem Handy haben.
Hat das schon jemand über die Bugreportfunktion gemeldet?

@thommyb Schade. Danke für die Rückmeldung.

Ich habs grad gefunden, und es hat sich grad erledigt.
Über den Kalender kann ich doch zu jeden Termin eine Eventvorlage auswählen, diese habe ich vorher angelegt und ausgewählt.
Die ist dann auch nur für die sichtbar, die für den Kalender auch sichtbar sind.
Aber jemand hat zur selben Zeit den Kalendereintrag verändert, wo ich daran gearbeitet habe, und ich hab mich gewundert, dass er plötzlich für alle sichtbar ist.

Habe das jetzt wieder rückgängig gemacht und jetzt klappt alles, so wie es soll!