@davidschilling Hmm, ich hab mir das schwieriger vorgestellt.
Solange ich über den LoginToken Arbeite ist das ja nicht so schwer wie ich dachte.
Nur, sollte ich es so machen, dass der User selbst mit seinen Userdaten sich anmelden kann, wirds vermutlich etwas umständlicher.
Hab neulich mit der Youtube API gearbeitet und hab immernoch Albträume von dem Autorisierungsprozess 😉 😃

@Silke-Falkner Hey, ich hatte deine Nachricht nicht gesehen.
Also wenn du magst kann ich dir meine Dateien schicken. Ich weiß nimmer auswendig was ich alles gemacht habe.

mark.erhard@efg-ochsenfurt.de

@Philipp-Klein dann müsste wie gesagt WorshipTools erstmal eine offene API anbieten. Was ich in deren Foren bisher gefunden habe, lässt nicht darauf schließen, dass eine Anbindung an Drittsysteme möglich ist ...

@MaxStro Ja über die Appointment-List 😉 Du kannst dir einfach zusammenkonfigurierten, welche Kalender angezeigt werden sollen: d58c5c9c-75e4-4f88-bb18-5ac68007b75b-image.png

@wolfgang-merkel

Wenn CT als Leitsystem verstanden wird, in der alle Personenbezogenen Daten gepflegt werden, liegt es nahe das auch zur Authentifizierung zu verwenden. Sonst musst du die Personendaten synchronisieren, das ist auch nicht sooo einfach

Aus meiner Sicht, macht es keinen Sinn, dass Church-Tools die Funktion eines Identity Providers (CIAM) implementiert, weil andere das Thema schon sehr professionell abliefern...

Das Argument ist schwierig, weil es für fast alle Funktionen von CT sicher irgendeinen gibt, der das "professionell abliefert" . Am Ende hast du x Systeme die irgendwas "professionell abliefern" und keine Integration mehr.

@thommyb Schade, aber trotzdem vielen Dank! Lässt sich nicht irgendwie sicherstellen, dass wenn man ein Treffen im Kalender über die API erstellt, auch automatisch ein Event erstellt wird? Genau so ist es derzeit in der Benutzeroberfläche:

Bild Text

@jmrauen : Da wir in unserer Gemeinde eine Fritz!Box als Router hatten, haben wir es mit Fritz!Dect-Thermostaten und Home-Assistant probiert. Bzgl Fritz!Dect 301 gibt es bereits eine gute Anleitung in deutscher Sprache:
https://smarterkram.de/3773/fritzdect-301-thermostat-fuer-den-heizkoerper-mit-home-assistant-steuern/
Dank der weiteren Starthilfe hier im Forum bzgl Churchtools Resourcen-Kalender und Home-Assistant funktioniert die Heizungssteuerung jetzt. Dem Herrn Jesus Christus sei Lob und Dank!

@Karl nein, das ist bisher nicht möglich

Heute ist mir aufgefallen, dass das Attribut data.churchdb.'edit groups' nicht mehr existiert. Es gibt nur noch das Attribut data.churchdb.'edit group'. Ich brauche diese Attribute nicht, aber vor einiger Zeit gab es das noch und jetzt gibt es Fehler beim Mappen des JSON zu meiner Klasse.

Wie beim letzten Mal taucht das Attribut außerdem weiterhin in der OpenAPI Dokumentation auf.

Ich habe für Korga auch einen eigenen ChurchTools Client in C# entwickelt: Source Code. Der ist auch alles andere als vollständig, aber funktioniert 😊

Sollte Michael Chen seine Cnml.ChurchToolsApi Bibliothek nicht weiterentwickeln wollen und Nachfrage bestehen, könnte ich meinen Client auch als NuGet Paket zur Verfügung stellen.

Eine Sandbox der eigenen Installation gibt es nicht. Aber du kannst gerne eine kostenlose Demo erstellen unter https://ccp.church.tools/demo und gegen diese Installation deine Implementierung testen.

@aschild Aktuell gibt es diesen Filter nicht

@davidschilling Ok, danke für die Erklärung mit den doppelten Daten 😉

Dann schreibe ich eine Mail mit unserem konkreten Bug...

Vielen Dank!

@davidschilling: Vielen Dank! - das hilft mir in einem ersten Step schon mal weiter. Konkret würde dein Lösungsvorschlag aber bedeuten, dass ich, wenn ich 100 Termine mit Anmeldung hätte, folglich 100 CURLs losschicken müsste um meine Verknüpfung zwischen Termin und Anmeldegruppe herzustellen? Gibt es hier noch eine andere Möglichkeit wo/wie ich diese gesammelt abfragen könnte? Danke!

@samu95 sagte in CT LDAP und Synology:

Ist mittlerweile schon ein Jahr her, aber ich habe mich in den letzten Wochen wieder mit dem Thema beschäftigt. Mit Hilfe vom Log und dem Synology Support habe ich festgestellt, dass die Verknüpfungen zwischen Benutzer und Gruppe zwingend eine Zahl sein muss. Der CT LDAP Server liefert aber den "Distinguished Name" (cn=user1,ou=users,o=xxx). Damit kann Synology nicht umgehen. Auch der Umweg über die HASH Funktion hilft da nicht weiter.

Gibt es hier vom Church Tools Support schon eine Information, ob man hier den CT LDAP Wrapper passend anpassen kann?

Das zukünftige OpenID Connect wird Synology leider nichts bringen, sofern man den Synology Drive Clienten nutzen will. Der unterstützt nach meinem aktuellen Stand kein SSO. SSO geht nur im Browser bei Synology.

Insofern wäre man hier dann doch wieder von der LDAP Integration abhängig.

@liebsoer Natürlich haben page und limit geeignete Default-Werte. (Beim limit diskutieren wir gerade noch, ob wir den Default auf 10 herabsetzen, um den Wert konsistent mit den meisten anderen unserer paginierenden APIs zu machen.)

Ein generelles Problem ist die von dir angesprochene Gesamtzahl der Ergebnisse. Wo wir sowieso alle Objekte laden (müssen), ist es leicht, auch die Gesamtzahl zurückzugeben. Wenn wir die Paginierung jedoch über SQL offset und limit abfackeln, steht uns diese Gesamtzahl nicht zur Verfügung, sondern müsste zusätzlich ermittelt werden, was in der Regel zulasten der Performance geht.

@liebsoer Wir haben vor einigen Monaten selber damit begonnen, aus der OpenAPI unsere Typen und Interfaces für die Kommunikation zu generieren. Dabei stolpern wir natürlich auch über die Dinge, die noch fehlen oder inkonsistent sind, und ergänzen diese entsprechend. Diese Arbeit geht zwar leider nicht über Nacht und auf einen Schlag, aber in den nächsten Monaten solltet ihr mit jeder neuen Version eine Menge Verbesserungen in der Spezifikation finden. Es lohnt sich also, immer wieder hineinzuschauen!