@liebsoer 👌🏽👌🏽
Vielen Dank!

@MichaelG Fakten sind ja immer an einem Event hängend. Aktuell haben wir nur die APIs, um die Fakten (Stammdaten) auszulesen und um Fakten eines bestimmten Events auszulesen/zu ändern.

Über Datum geht nicht, weil das ja nicht eindeutig wäre. In welches Event soll das Faktum geschrieben werden, wenn es mehrere Events zur selben Uhrzeit gibt?

Einen importer, wie du ihn dir vorstellst, gibt es aktuell nicht und du müsstest über die Event-API das jeweilige Event herausfinden. Die API /events kann auch mittels Datum eingegrenzt werden, um ein Event zu finden.

Mit der Event-ID kannst du dann die Fakten-API nutzen, um den einen Fakt zu speichern.

@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

@Karl nein, das ist bisher nicht möglich

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!

@MaBo Nicht mehr zugewiesene Tags werden mit dem nächsten Cron-Job automatisch entfernt.

@jziegeler danke, ich musste nur ne Nacht drüber schlafen...

Ich habe im payload immer song_id statt id verwendet.

@ben-ste ja, das hat mir auch am Anfang Kopfzerbrechen bereitet...
daher: +1