@kgghhf kontaktiere den Support und lass sie in eure Instanz schauen. Die finden den Fehler.

@JJB & @Andy Das stimmt, wenn ich einen Wochentag eingebe, dann kann ich danach auch filtern, danke!

Aber wie funtioniert das für eigens angelegte Datenfelder?

Ich habe ein Datenfeld 'Land' für Gruppen angelegt:
d1a2c63e-386d-460e-a6ac-5700e50856f3-image.png
Und auch einer Gruppe ein Land zugewiesen:
d04ec532-10a2-4975-82d3-e1a241b6005d-image.png
Aber ich kann nicht nach 'Land' filtern:
d5e57332-77b4-443b-9c77-a08c907124cf-image.png

Gibt es dafür auch eine Lösung?

Und außerdem würde ich das eigens angelegte DB-Feld auch gerne in der kleinen Vorschau sehen, kann man das auch einstellen? (Wochentag sehe ich aber 'Land' nicht) Dafür gibt es auch schon eine Frage
24021269-06a6-4fbc-bbef-465cd38ecfc9-image.png

@jjb Der Support hat sich bei uns das Problem mal angeschaut und ich kann nun bestätigen, dass dies ein echtes ChurchTools-Problem ist, von dem ich mir die Behebung wünsche.

Um die Kommentarfelder der angemeldeten Personen in der Tabelle zu sehen, muss das Recht "Gruppenteilnehmerstatus editieren" vergeben werden. Wir haben dieses Recht nicht vergeben, daher sehen unsere Organisatoren die Texte in der Tabelle nicht. Trotzdem bekommen sie sie per Mail zugestellt.

Wir wollen in unserer Gruppe nicht, dass die Organisatoren zusätzlich das Recht "Gruppenteilnehmerstatus editieren" bekommen. Denn damit lassen sich Anmeldedaten und Rollen verändern. Insbesondere könnten die Organisatoren andere Organisatoren benennen. Das wird bei uns aber von anderer Stelle geregt.

Ziemlich unbefriedigend, unseren Organisatoren nun zu sagen, sie sollen halt in ihre Mails gucken, wenn ChurchTools die Bemerkungen eigentlich in die Tabelle integrieren könnte.

Noch einmal zu Erklärung, warum das nicht nur ein unschönes Verhalten, sondern tatächlich ein Bug ist, der behoben werden sollte: Wenn man schon zwei Rechte, die eigentlich nichts miteinander zu tun haben, kombiniert, dann sollte man es konsequen machen. Dass die Texte per Mail eingesehen werden können, parallel in der Tabelle aber verboten werden, ist ein "Rechtsbruch".

@jziegeler

Das stört mich auch schon länger, dass die Gruppe entweder nicht sichtbar oder für alle öffentlich ist. Dazwischen gibt es nichts. Und da wäre es sehr hilfreich, bestimmte Personen einladen zu können, ohne dass die Gruppe für alle sichtbar ist.

Hatte hier mal ein FR dazu erstellt. Zwar nicht mit aktiver Einladung, aber halt mit einem Link zum verteilen.
https://forum.church.tools/topic/7585/gruppeneinladung-per-link-ohne-öffentlich-sichtbar

@jakob-hd Ich habe mir für diesen Zweck eine Gruppe eingerichtet, die keiner sonst sieht. Dort packe ich die Personen rein, die schon eingeladen sind. So kann man leicht die ausfiltern, die es noch nicht sind. Außerdem regeln wir unsere unterschriebenen Datenschutzerklärungen auch mit Gruppen. Bei uns wird nur jemand eingeladen, der vorher seine Erklärung unterschrieben hat. Aber hier kann man ja auch super filtern: Datenschutz ja, Eingeladen nein.

Das ist ein Ding ... gerade eben stoße ich auf dasselbe Problem!
Das Gruppen-interne Recht, Ablaufpläne zu editieren, sollte doch eigentlich genügen, die Ablaufpläne für Events des entsprechenden Kalenders abzurufen und zu verwenden.

@ulrich-graefe Kann es hiermit zusammen hängen?

@jjb also unüblich ist es nicht die Berechtigungen Anlage, Pflege und Löschen zu trennen. Weshalb das in CT bei den Beziehungen so gehandhabt wird, müsste EW/PO was zu sagen.

@jjb Guck mal hier ...

@antester Nee, das ist doch kein Sicherheitsrisiko.

Im Gegenteil, es ist gut, dass man nach einem Logout nicht mehr eingeloggt ist 😉

Und das darf natürlich auch durch die passende Fehlermeldung kommentiert werden.

@hubert-s Vielen Dank für diesen Vorschlag. Darüber habe ich auch schon nachgedacht. Je nach Situation könnte das eine gute Lösung sein.

Danke @all. Dann warte ich auf die Fehlerbeseitigung. Lg

Hi,
für andere, die es auch anfangs vergeblich suchen, hier wird die LDAP (und auch LDAPS) Integration beschrieben:
https://hilfe.church.tools/wiki/0/LDAP-Integration

Ich kann nun bestätigen, das Problem hat sich bei uns dadurch lösen lassen, auf das Komma am Ende nach der letzten ID zu verzichten. Habe das auch vom Support bestätigt bekommen. Mit dem nächsten Software-Update von CT sollte es aber auch mit dem Komma keine Probleme mehr geben. Ist also nur eine Übungangslösung, bald kommt die richtige.

Weil wir das Komma da schon von Anfang an drin stehen habe, vermute ich mal, dass in der letzten Zeit irgendetwas an der Programmierung der Ressourcen verändert wurde, so dass es überhaupt erst zu diesem Fehler kam.