Mitglieder sollen andere Mitglieder in der Personenliste sehen

schpaik

Ich stehe irgendwie gerade auf dem Schlauch:
Wenn ich in die Simulations-Ansicht unserer Mitglieder gehe, dann sehen diese entweder nur sich selbst oder die Mitglieder der Gruppen, in denen sie sind.
Ich hatte in Erinnerung, dass CT standardmäßig so konfiguriert ist, dass Mitglieder die Daten des Sicherheitslevel 1 der anderen Mitglieder ebenfalls sehen können.
Hab ich mir das falsch gemerkt, hab ich irgendwann mal etwas "kaputt-konfiguriert" oder mache ich etwas falsch?

Ich habe bereits überprüft:

Status "Mitglied" hat das Recht
- Personen & Gruppen sehen
- Sicherheitslevel Personendaten Stufe 1
- Sicherheitslevel Gruppendaten Stufe 1
- Sicherheitslevel Eigene Daten Stufe 2
Zahlreiche DB-Felder haben den Sicherheitslevel 1, u.a.
- Vorname
- Name
- PLZ
- Ort
- E-Mail-Adresse

Wo kann ich noch suchen bzw. wo steckt der Fehler?

jziegeler

@schpaik die Daten von anderen Personen über das Sicherheitslevel sehen zu können, bedeutet nicht, dass ich diese Person auch sehe das funktioniert nur über Gruppen oder Bereiche sichtbar machen.

Schau dir mal diese Matrix an: https://intern.church.tools/?q=churchwiki#WikiView/filterWikicategory_id:0/doc:Gruppensichtbarkeiten/follow_redirect:true/

schpaik

Danke, das war ein erster Schritt.
Nun habe ich über das Recht "view_alldata" einen Bereich für Mitglieder komplett sichtbar gemacht.
Jetzt möchte ich dieses Recht aber gerne so einschränken, dass in der Liste auch nur andere Mitglieder sichtbar sind. Interessenten o.ä., die noch keine entsprechende Freigabe für Ihre Daten unterzeichnet haben, sollen nicht sichtbar sein.

Kann ich das nur lösen, indem ich diese Personen in einen eigenen Bereich verschiebe?

jziegeler

@schpaik ja

schpaik

@jziegeler Hm, nur damit ich es richtig verstehe:
Es ist nicht möglich, allen "Mitgliedern" (Status) Zugriff auf die Personenliste der anderen "Mitglieder" (Status) innerhalb eines Bereichs zu geben (quasi ein mehrstufiger Filter Bereich -> Status).
Ich müsste dafür alle Personen, die einen anderen Status haben in einen anderen Bereich verschieben?

jziegeler

@schpaik es gibt verschiedene Varianten. Du kannst auch nicht mit den Bereichen arbeiten und die Mitglieder alle in eine Gruppe tun, in der sie sich sehen ... es führen letztlich viele Wege nach Rom, es kommt drauf an welches Konzept für euch passt und was du genau erreichen willst.

MarkusU

@jziegeler Aber das ist doch irgendwie doppelte Datenhaltung. Dann muss ich ja immer darauf achten, dass die Mitglieder immer den Status "Mitglied" haben und dazu noch z. B. in der Gruppe "Mitglieder" sind...

Warum ist es nicht möglich, einzustellen, dass Personen desselben Status sich gegenseitig in der Personenliste sehen können (so wie bei Gruppen)? Wir haben inzwischen zwei Gruppen angelegt (eine für unsere Gemeindemitglieder, eine für die EC-Mitglieder der Jugend), damit sie sich gegenseitig "sehen" können. Zusätzlich haben wir schon länger zwei zugehörige Bereiche. Wo kann man die Sichtbarkeiten (aber nur der Mitglieder untereinander) der Bereiche einstellen?

Die Mitgliederliste auf der Startseite wird von sehr vielen nicht gefunden und sehr häufig nicht verstanden. Wenn ich Kontakt aufnehmen möchte, klicke ich natürlich in die Personenliste...

thommyb

@markusu Wir haben in "Rechteverwaltung -> Status -> Mitglied" u.a. folgende Rechte konfiguriert:

Personen & Gruppen: "Personen & Gruppen" sehen, Alle Personen des jeweiligen Bereiches sichtbar machen (Gemeinde)

Ich denke, das erfüllt den von dir beschriebenen Zweck.

BeMiGro

Das Grundproblem ist, daß man zwar einerseits an den Status bestimmte Berechtigungen hängen kann, aber andererseits nicht auf den Status berechtigen kann.
Ich finde das auch unintuitiv und wenig hilfreich.

Für das Thema gibt's auch schon mindestens zwei Feature Requests:

Ich würde vorschlagen, dort zu voten.

bwl21

@bemigro du kannst auf den Status verzichten und alles über Gruppen machen.

MarkusU

@thommyb Vielen Dank für den Vorschlag und die fixe Idee.

Aber leider hilft uns das nicht wirklich weiter. Denn im Bereich tummeln sich ja nicht nur Mitglieder, sondern auch Besucher, Teilnehmer etc.

Und wir möchten, dass Mitglieder nur andere Mitglieder sehen können und nicht "Alle Personen des jeweiligen Bereiches". Daher ist der Gedanke gut, aber leider datenschutzrechtlich nicht das, was wir brauchen.

Und nein, wir werden nicht noch zusätzlich verschiedene Bereiche für die Kombinationen noch Bereichen (bei uns Jugend und Gemeinde) und Mitglied bzw. Nicht-Mitglied erstellen und manuell pflegen. Dann bleiben wir lieber bei den zwei relativ offensichtlichen Gruppen.

MarkusU

@bwl21 Nein, das ist uns nicht möglich, da unser Dachverband via SYNC die Mitgliederdaten mit einem bestimmten Status ("Mitglied") und in einem bestimmten Bereich ("Gemeinde") nächtlich abgleicht.

bwl21

@markusu dann entziehe dem Mitglied sämtliche Rechte, oder sprich das Problem bei eurem Dachverband an .

BeMiGro

@bwl21 Theoretisch ja, praktisch nein.
Wie bei @MarkusU hängt da bei uns die Synchronisation im Verband dran. D.h. wollte man tatsächlich den Status komplett aufs Altenteil schieben, hängt da der Umbau einiger Dutzend CT-Instanzen dran. Da das Thema bei uns im Wesentlichen ehrenamtlich läuft, sehe ich nicht, daß dafür auf absehbare Zeit Luft ist.

Außerdem hat der Status gegenüber Gruppen einen wichtigen Vorteil: er ist eindeutig, eine Person kann nur genau einen Status haben. Bilde ich Mitglieder und Nicht-Mitglieder dagegen über Gruppen ab, kann es vorkommen, daß eine Person in beiden Gruppen ist - und die DAtenbais damit inkonsistent.

Das Gleiche gilt, wenn man Status & Gruppen parallel verwendet, früher oder später treten in so einer Konstellation Inkonsistenzen auf. Natürlich kann man das über Skript-Lösungen, die sich der CT-API bedienen, verhindern. Die Leute, die so etwas entwickeln und betreuen, muß man allerdings auch erstmal haben (von der Frage, ob diese CT-externe Verarbeitung von Personendaten überhaupt statthaft ist, mal ganz abgesehen).

Mein persönliches Fazit: die vorgeschlagenen Ansätze über Gruppen sind valide Workarounds, eine echte Lösung ist für mich nur, auch auf den Status berechtigen zu können. Für ein derart zentrales Merkmal ist das m.E. auch durchaus angemessen.
Sollte der Status CT-seitig als Auslaufmodell betrachtet werden, lohnt eine FR-Implementierung dafür natürlich nicht mehr. Dann sollte der Status aber auch entsprechend als "deprecated" gekennzeichnet werden.