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

@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

Hallo, du hast vollkommen recht, die Arrays müssen in der URL mit eckigen Klammern wie account_ids[]= aufgeführt werden. (Die Zahlen in den Klammern sind nicht zwingend notwendig).

Wir haben hier aktuell ein Problem mit der Swagger UI, also dem Interface, dass die API Dokumentation hier visuell rendert.

Du musst wissen, alle Arrays, die in der URL als GET Parameter übergeben werden sollen, müssen immer diese eckigen Klammern haben.

Ich guck mir das Thema noch mal an und hoffe, dass ich den Fehler beheben kann in der UI. Die API an sich funktioniert korrekt.

@diging hab gerade mal im Code geschaut, die Funktion ist einfach nicht per API erreichbar. Was du nutzen könntest wäre: oldApi('churchcal', 'getBirthdays').then(result => { und dann halt selbst noch mal filtern ... Eine andere Möglichkeit sehe ich zurzeit nicht.
Auf der näheren Agenda steht aber auf jeden Fall auch die REST-API für Geburtstage, das wäre dann natürlich komfortabler, da kann ich dir allerdings noch keinen Termin nennen.

@Daniela-Giese Wir bieten eine eigene REST-Api, diese kannst du natürlich nutzen um an eine andere API wie die von Rapdimail anzubinden. Das muss dann allerdings außerhalb von Churchtools angestoßen werden

Vielen Dank für die schnelle Rückmeldung! Genau, in der Historie sind alle Informationen, die ich gesucht habe! Perfekt, wenn diese in der REST-API abgerufen werden können!

@jziegeler: Hallo, richtig, der iCal fkt. einwandfrei. Wg. Cronjob muß ich mal mit dem Server-Admin sprechen. Ich hab keine Ahnung, was da zu tun ist. Gruß, Gerald

@jziegeler Cool! Vor allem, wenn man das aus seinem Kalender automatisch vorbelegen kann. 😉

Die Planung über CT schau ich mir mal an. Danke für die Hinweise!

Gibt es ein paar Codeschnipsel, mit denen ich so einen Upload/POST tortzdem mal probieren kann?

So, ich habe eine für uns brauchbare Lösung gefunden 🙂
Da wir Churchtools selbst hosten und es sich bei der gesuchten Funktion IMMER um die Freigabe eines Serientermins handelt, kann ich die Aufgabe ganz einfach dadurch lösen, indem ich direkt in die Datenbank in die Tabelle cc_cal_except eine Terminausnahme rein schreibe.
Ist zwar nicht ganz so schön wie über eine offizielle API Funktion, hilft uns aber erst mal weiter.

Vielen Dank!