@jziegeler Ich kenne die interne Datenstruktur von Churchtools selbst auch nicht, da ich kein Zugriff auf eine Installation habe. Ich möchte aber wirklich genau wissen, wie die Daten in der Datenbank abgespeichert werden und wie die Daten miteinander verknüpft sind, da man ja nicht unendlich viele Events in der Datenbank anlegen kann für Dauerevents, die nie aufhören. Trotzdem ist es ja irgendwie möglich, mit einem Event andere Daten zu verknüpfen und genau das brauche ich.

@jziegeler sagte in Wie kann ich custom-Felder in Gruppenmitgliedschaft per API setzen:

/groups/{id}/members liefert dir alle TN mit den entsprechenden Sonderfeldern

Bei mir werden mit dem Aufruf keine Sonderfelder zurück gegeben oder zählen die Personenfelder (Anschrift und Telefonnummer) nicht als Sonderfelder? Das Array fields (falls die dort aufgelistet werden sollen) ist leer:
6a00fcb2-4260-4b00-b5b3-9469f353efba-image.png

/groups/{id}/memberfields liefert dir die Definition der Felder

Hier werden die vier Personenfelder für die Gruppe aufgelistet, deswegen vermute ich, dass diese auch unter fields vorhanden sein sollten.

In der API wird das Feld "angemeldet von" noch nicht mit überliefert. Wird das noch kommen?

@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.

Ich hätte sonst nur die Idee einmal alle Fakten auszulesen und sie möglichst maschinenlesbar z.B. auf eine Wiki Seite (die nur der Benutzer den ich fürs Fakten auslesen angelegt habe sieht) zu speichern.
Bei den folgenden Abfragen, werden dann wie gehabt nur die neuen Events/Fakten geladen und das Programm kombiniert die neuen Daten mit den historischen der Wiki-Seite und ergänzt die Wiki-Seite wieder entsprechend.
😁

@aschild Das wäre auszuprobieren.

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

@gabi sagte in Schnittstelle zu Mailpoet:

In diesem Forum wird ständig Fachsprache benutzt, die nicht erklärt wird.

Oh, ok. Einfach immer nachhaken, wenn etwas unverständlich ist.

@davidschilling Ich habe versucht, das Passwort in JSON zu senden. Sobald aber bestimmte Sonderzeichen enthalten sind, erhalte ich "Passwort ist falsch" zurück.

$url = 'https://xxx.church.tools?q=login/ajax&func=getUserLoginToken'; $data = array( 'email' => $email, 'password' => $password, 'directtool' => 'yes' ); $options = array( 'http' => array( 'method' => "POST", 'header' => "Content-type: application/json" ."\r\naccept: application/json", 'content' => json_encode($data) ) ); $context = stream_context_create($options); $result = file_get_contents($url, false, $context); $data = json_decode($result);

@hgransow du brauchst vor der alten api keine Angst zu haben. Wen man mal weiß wie es geht, kommt man damit auch gut klar.

und bis CT komplett auf der neuen API ist wird es m.E. noch einige Zeit dauern (bis dahin ist REST schon wieder old school 🙂

Ich hab mich mit api V1 arrangiert. Seien wir doch froh, dass sie schon JSON liefert.

Danke für das Feedback. Ich werde mir das mal angucken.

@davidschilling sagte in Abfrage bzw. setzen der Permissions per API:

schau am besten mal in eurem ChurchTools Log nach ob dort ein Fehler sichtbar ist.

warum bin ich auf die Idee nicht selbst gekommen? Da stand die Lösung: Der will als data echt einen json-String sehen, der dann nochmal beim Senden nochmal mit http_build_query verpackt werden muss.

vielen Dank für den Hinweis.

Support hat gentwortet:

Mar 23, 15:29
Hallo,

wir haben es noch mal geprüft und ja die Tabelle wird wirklich nicht vernünftig aufgeräumt. Es gibt nach unserer Einschätzung keine Seiteneffekte, daher ist es nicht schlimm. Danke für den wertvollen Hinweis. Wir haben es als Bug aufgenommen und werden das beheben.

@jziegeler Vielen Dank für den Hinweis. Da hat aber jemand eine Abkürzung genommen 🙂

Mein Recheteauswerteprototyp funktionier da sogar zufällig (im wahrsten sinne des wortes ...) weil er die gruppen ohne Typprüfung der ID sucht, und daher über "10101" auch "10101D" findet.

Ich werte die Jsons über JSONpath aus.
$__authrecord = $masterdata_jsonpath->find("$..auth_table..[?(@.id=='$_auth_key')]")[0];

Das läuft gut und ist für meine Anwendung ausreichend schnell obwohl da zwei "deep serach operationen" drin sind ..

Auch in diesem Fall ist der Browser wieder unser Freund und kann uns helfen zu verstehen wie man Cookies sendet.
Einfach mal die Entwicklerkonsole im ChurchTools Frontend öffnen und die Header eines Requests anschauen.

Schlussendlich muss das Cookie als Header geschickt werden. Hier die Dokumentation von Mozilla dazu: https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cookie

curl_setopt($ch, CURLOPT_HTTPHEADER, array("Cookie: ct_testdavid=bizlub34qv5b03457nqvb3547"));

@davidschilling

@davidschilling sagte in Benennungen der API manchmal nicht ganz konsistent:

Da sind wir dann unterschiedlicher Meinung. Für mich ist an der Stelle person ein Domain Type und der ist erstmal in der Einzahl außer es handelt sich um mehrere. Da geht es um das Konzept der Person und nicht um eine oder viele.

Ja das kann ich nachvollziehen und ändere da gerne (meine ohnehin nur mäßg relevante) Meinung. Danke für die Erläuterung.

Dann müsste man vielleicht auch masterdata/person zu person/masterdata/roles machen.

@bwl21 sagte in Familien anlegen per API:

Ich bekomme die Meldung: Keine ausreichende Berechtigung. Das Recht 'view person ("Verwaltung")' ist notwendig.,
Ich finde aber kein Recht view person. Wenn ich die Beziehung Frontend eingebe, dann funktioniert das ohne die Fehlermeldung.

da waren nun doch Fehler in den Parameternamen. Die Fehlermeldung ist da dann nicht wirklch hilfreich, es ist kein Problem der Berechtigungen ....

nun denn. auf jeden Fall läuft es jetzt.

Kurzes Update: der Bug im Filter wird in der Version 3.71 (vermutlich ab 22.03.) gefixt sein