Vielen Dank @skipy @bwl21 für die Hinweise. Die Fehler in der API sind sicherlich nervig, gerade wenn man richtig loslegen möchte.

Ich habe die, hier im Thread erwähnten, Dinge behoben für v3.78

/groups Response richtig dokumentiert page Example Value auf 1 gesetzt QueryParameter richtig dokumentieren

@dumbergerl @skipy @MichaelG
Danke euch allen für eure Antworten, das hat auf jeden Fall geholfen. Danke auch @DumbergerL für deinen Wrapper, den hatte ich beim Googlen nicht gefunden, der sieht ja aber super aus. Ich denke den werden wir nutzen.

@castilma ja da hast du recht. Wir haben noch eine ganze Liste von undokumentierten apis, die darauf warten abgearbeitet zu werden. Login gehört auch dazu.

@davidschilling Also es sind verschieden Tools bzw. Zugriffsversuche.

das eine ist der Zugriff über Windows IE Explorer Platform
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775123(v=vs.85)

Das andere ist eine Komponetensammlung:
TMS VCL Cloud Pack
https://www.tmssoftware.com/site/cloudpack.asp

Beide gehen nicht.

Die dritte Variante die ich nun habe ist über Indy-Komponenten:
https://www.indyproject.org/about/
dort funktioniert es.

Ich kann mich da meinen Vorrednern nur anschließen. Es macht leider echt keinen Spaß und ist defakto fast unmöglich mit der Openapi.json zu arbeiten, weil so viele Fehler drin sind. Zudem bin ich etwas frustriert, was die Antwortzeiten angeht, wenn man einen Fehler in der Openapi.json meldet.

@hbuerger Was war das Ergebnis vom "angucken"?

Hat sich da seit April was getan? Möchtet ihr, dass wir als Entwickler aktiv Fehler melden oder empfindet ihr das eher als nervig? Wie können wir als externe Entwickler diese Fehler so melden oder sogar selbst korrigieren, dass sie schneller im Produktiv-System landen?

@skipy sagte in Openjson Fehler: person/masterdata:

Oder noch besser:
Nach meinem Verständnis bräuchte es in der Openapi.json bei boolean Werte gar kein enum. Per Definition können Werte vom type boolean nämlich nur true oder false sein.

Du steigst da gut und tief ein. Vielen Dank. Es sind oft diese Kleinigkeiten, die einem das Leben schwer machen. Ähnliche Probleme gibt es manchmal mit IDs, die mal als Integer und mal als String zurückkommen.

Apropos Bool: Ich persönlich würde ja empfehlen auf bool ganz zu verzichten. Irgendwann kommt mal ein Fall hinzu wo man nicht mehr nur zweiwertig unterwegs ist. In der Regel braucht noch noch einen Neutralwert wenn man da nicht null nehmen will. Daher fände ich das mit den enum schon besser (und zukunftssicherer)

@ernst-egb beim support melden, dann wird der LDAP Dienst eingerichtet.

Danke @davidschilling für deine Rückmeldung. Die ist sehr willkommen.

Eine Möglichkeit, dass sich (auch nicht CT-Nutzer) DSGVO Konform von Newslettern abmelden können.

Das ist aktuell möglich über den Abmeldelink den man in der ersten Mail nach der Anmeldung in einer öffentlichen Gruppe bekommt.

Leider ist genau das gerade eben unser Hauptproblem. Der aktuelle Weg, wie ChurchTools E-Mails verschickt ist eben nicht DSGVO konform. Denn wenn ich die DSGVO richtig verstehe, muss eine "Abmeldung vom Newsletter jederzeit möglich sein".

Hier einige konkrete Beispiele, die eben nicht funktionieren:

Ein Nutzer hat die erhaltene Gruppenanmelde-EMail gelöscht Die Anmeldung in einer Gruppe liegt viele Wochen zurück und ein Nutzer findet seine Anmelde-EMail nicht mehr Ein Nutzer hat sich bei mehreren Newslettern der Gemeinde (aka Gruppen) registriert. Er will sich jetzt nur (!) von einem abmelden. Aber wenn es nicht explizit in der E-Mail erwähnt ist, findet er nicht heraus, über welchen Gruppenverteiler eine Mail verschickt wurde und kann sich dementsprechend auch nicht abmelden.

Laut DSGVO muss eine Abmeldung auch dann möglich sein, wenn der E-Mail-Support (z.B. am Wochenende) nicht zur Verfügung steht. Es braucht also eine technische Lösung. Derzeit bietet Churchtools meines Wissens allerdings keine Möglichkeit für Nicht-Churchtools-Nutzer sich jederzeit wieder abzumelden.

Als Defakto-Standard hat es sich bei Newslettersystemen eingebürgert, dass man im Footer einer erhaltenen E-Mail individuell generierten Hash eingebettet bekommt, der einen zur individualisierten "Abmelde-Homepage" führt. Somit kann er sich jederzeit von seinem Newsletter abmelden. Eine solche Möglichkeit würde ich unbedingt vorziehen, aber ist bisher in ChurchTools nicht vorhanden. Wenn so etwas in nächster Zeit geplant ist, wäre mir das viel (!) lieber, als es selbst programmieren zu müssen. 🙂

Die Lösung mit einer zentralen Webseite, wo alle öffentlichen Newsletter einer Person einsehbar und veränderbar sind, ist nur ein Workaround. Lieber wäre es mir, das in CT von Haus aus machen zu können.

@davidschilling ok, das heißt man muss ständig eine neue Gottesdienstserie anlegen? Wie lange wäre denn die längste mögliche Serie? Ich kann das leider selbst nicht überprüfen, da ich nur einen Gastzugang zu einer Churchtools Instanz habe.

@markusp du kannst auch den Endpunkt /persons?ids[]=..... verwenden, dann ist es nur ein Aufruf die Dokumentation findest du unter deineGemeinde.church.tools/api

@jziegeler danke, schon mal gut, dass ich so direkt einladen kann zu CT in die Gruppe. Langsam begreife ich das CT – Konzept, entscheidend sind oft die Berechtigungen. Alles klar erst mal! Danke euch! 👌

@jziegeler Danke! Ja, ich hatte dann auch weiter gesucht und habe iFrame erfolgreich 🤩 eingesetzt. Nun habe ich eine weitere Frage, dazu ein weiteres Thema ... Gruß & Segen! 😍 Michael

Falls es jemanden interessiert: Es geht noch einfacher.
Ich benutze jetzt die Funktion loadQuery vom Report-Modul:

xyz.church.tools/?q=churchreport/ajax&func=loadQuery&id=4

wobei id=4 in unserem Fall die Fakten-Abfrage für den Fakten-Adhoc-Report ist.
Zurück bekomme ich alle Fakten über den gesamten Zeitraum, seit wir ChurchTools nutzen 👍

@jziegeler
danke dir, dort hätte ich es nicht erwartet.

Gibt es einen Grund, warum man das Recht zum "Berechtigungen anpassen" (administer persons) benötigt? Mit dem API Call kann ich ja keine Berechtigung ändern, sondern nur eine Personenliste (nur die ID) abholen.

"Administer persons" und "Berechtigung anpassen" sind doch zwei komplett unterschiedliche Sachen. Die Rechteverwaltung beziehen sich ja auch auf Status, Gruppentypen und Gruppen. Da ist "administer groups" hier schon viel verständlicher: Gruppen administrieren, d.h. erstellen, löschen, etc.

Leider verhält sich der API Call nicht so wie ich es erwartet hätte. Ich dachte, dass dort dann nur die für den Benutzer sichtbaren Personen zurück geworfen werden, aber es werden auch für ihn nicht sichtbaren User zurück gegeben. Dann muss ich mir hierfür etwas anderes überlegen.

@markusp für application/json ist es nicht notwendig.

CSRF ist eine Sicherheitslücke die über Formulare in Browsern passieren kann. Wenn du einen ajax request im browser machst kannst du keinen csrf ausnutzen.

@aschild Das wäre auszuprobieren.

Du kannst aber sicher ein neues Feld mit dem neuen Namen anlegen und einen wenigzeiler schreiben, der das umkopiert.