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.

@narnitz merci ❤

noch hab ich das mit TOTP nicht zum laufen bekommen, doch der rest funktioniert super.

(wer genauers wissen will kann hier schauen: GitHub - ChurchTools-song-checker)

Nun aber genug mit OT 🙂

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

in den nächsten Tagen wird eine Skript für die CCU von Homematic fertig mit dem man die Heizung steuern kann. Siehe Google "Diedrichs Heizkalender" oder https://diedrichs.de

@DaniBaumann Die Api kam in der Version 3.107 dazu.

@samu95 zeige ich dir sobald ich wieder am Rechner bin sehr gerne.

@MichaelG schreib mir die Fehler mal direkt, dann schau ich mir das an, dass die api dort fehlerfrei wird