@andrea-schulz

verstehe, das wäre eine interessante Lösung. du meinst "abwesenheiten in Gruppe xy" . Dort packt man die Leute rein, deren Abwesenheit man sehen möchte.

Das könnte ja dann ein Feature der Gruppe sein, dann kann sich jeder seine Abwesenheiten zusammenstellen.

D.h. bei einer Gruppe gäbe es die funktion "abwesenheiten abonnieren" ...

@Karl Nein, das ist bisher noch nicht möglich

@jziegeler Ah ok. Vielen Dank! Das funktioniert. Danke für den Tipp.
Ich habe es hier gesehen: https://api.church.tools/function-churchcore_sendEMailToPersonIDs.html

@davidschilling Hmmm...
da sehe ich jetzt gerade nicht wie das funktionieren soll.

Im /calendars/appointments fehlen mir die Ressourcen
Im /calendars/{id}/appointsments hier auch

Wir haben Keycloak mit dem Plugin von @simsa jetzt seit gut 6 Wochen produktiv im Einsatz:

Nextcloud via user_oidc WordPress via OAuth Single Sign On - SSO (OAuth Client) Korga (E-Mail-Verteiler-Erweiterung für ChurchTools)

Das Format des sub Claim von Keycloak mit Doppelpunkten macht die Einrichtung hier und da etwas schwierig, aber mit der richtigen Konfiguration läuft es seitdem einwandfrei.

Weil Keycloak auf einem anderen Origin als ChurchTools läuft und damit de facto eine Man-in-the-Middle-Attacke wie eine Phishing Seite ausführt, bekommen Nutzer nur vom Apple Schlüsselbund kein Passwort oder das falsche Passwort vorgeschlagen und müssen es manuell auswählen. Das ist sicherlich keine tolle Lösung, aber für uns akzeptabel, bis ChurchTools irgendwann selbst OpenID Connect einführt.

@wulmer sagte in Service Account // System User Token:

Ein Token (welches dann auch kein verwirrendes Session-Cookie des technischen Users erfordert) wäre da sehr hilfreich.

Was du suchst, ist vermutlich das Login Token. Das ist zeitlich unbegrenzt gültig und ermöglicht die Authentifizierung über den Authorization Header ohne Cookies.

⚠️ Ich würde dir jedoch dringend davon abraten, Login Tokens im JavaScript einzubinden und damit öffentlich ins Internet zu stellen. Auch die aktuelle Lösung, die du beschreibst, klingt gefährlich. Wenn euer Systemnutzer aus irgendeinem Grund z.B. einer Gruppenmitgliedschaft zu viele Berechtigungen erhält, sind schnell sehr viel mehr Daten öffentlich einsehbar, als du möchtest.

Aufwändiger aber deutlich sicherer wäre ein Backend, dass ausgewählte Informationen eurer Website über eine eigens dafür konzipierte API zur Verfügung stellt. Ich bin jetzt kein PHP Experte, aber mit den Libraries die es gibt, sollte das in unter 50 Zeilen Code umsetzbar sein.

@thommyb sagte in Kalender REST API Berechtigungsproblem seit v3.103.1:

@aschild Ist vielleicht eine blöde Frage, aber warum gibt es denn diese Retry-Logik? Warum schickst du nicht gleich/immer den Login-Token mit?

Wenn du mir sagst wie man das mit eurem JS client macht, dann her mit den Infos 🙂
In den anderen Clients (php etc.) wird das lgin token defaultmässig immer mitgesendet

@Peter-Grab schau mal hier: https://hilfe.church.tools/wiki/0/CleverReach-Integration Das sind zwar noch Screenshots für die Version 2, aber die Felder gelten weiterhin

@DumbergerL Danke für die gute Erklärung
@corth50 hier noch unsere Hilfe Seite zum CSRF: https://hilfe.church.tools/wiki/0/API-CSRF

@schowave Hier
e28b740b-2681-4245-bff7-6a2b17da6b45-grafik.png

Mich würde euer Ergebnis interessieren, weil wir auch schon seit längerem auf so eine Option schielen. Habe da vor Jahren auch schon mal einen Feature Request erstellt:

https://forum.church.tools/topic/7198/eigenständiger-checkin?_=1699433331938

Das würde auch für Ferienfreizeiten bei uns total hilfreich sein. 🙂

@aschild Top, danke! Das hat funktioniert!

@kiesldusl Da wir nur das ofizielle REST API von Churchtools verwenden: ein klares ja.
Und gerne Feedback/Erweiterungswünsche in den Github issues erfassen

@karin-d Danke für den Hinweis! Ich habe mal im Log geschaut und tatsächlich gibt es da seit dem 11.10. auch immer wieder mal einen entsprechenden Eintrag für Requests, die nicht von meinem Code, sondern entweder vom Web-Frontend oder von der App kommen.

Ich gehe also stark davon aus, dass es ein Bug ist, der mit dem Update auf v3.102.0 reingekommen ist.

@aschild Das wurde wohl in der REST-Api vergessen. Das werden wir dann noch einbauen.

Update Sept. 2023:

Es gibt mittlerweile einen eigenen API Endpunkt, mit dem sich zu einem Termin (Appointment) die zugehörigen Buchungen und das Event abrufen lassen:

/calendars/{calendarId}/appointments/{appointmentId}/{startDate}

@aschild Hat den Endpunkt auch für den ChurchTools-API Wrapper umgesetzt:

$calendarId = 2; $appointmentId = 13; $combinedAppointment = CombinedAppointmentRequest::forAppointment($calendarId, $appointmentId, "2023-10-01")->get(); $appointment = $combinedAppointment->getAppointment(); // see Appointment-Model $event = $combinedAppointment->getEvent(); // see Event-Model $bookings = $combinedAppointment->getBookings(); // see Booking-Model

Siehe Dokumentation.

@jziegeler Das Problem ist, dass wir da keine AddressID haben und somit keine logische Zuordnung möglich ist.
Und der /address Endpunkt würde dann auch fehlen.

Aber Danke für's anschauen

Wir haben ein bisschen dran rumgeschraubt.
https://gitlab.com/immanuelrv/churchcal-sync

Das Plugin läuft nun mit der neuen API
Dadurch können mehr Funktionen abgebildet werden.
Veranstaltungsbilder werden nun im Pop-up angezeigt.