Vielleicht macht es aber Sinn, einfach die Möglichkeit Chats zu sehen, in der Simulation technisch zu verhindern, oder?

Mit der CT-App gibt es (abgesehen von Gruppenhomepages) zum ersten Mal so etwas wie ein nutzerfreundliches Frontend, das ich in der Webansicht sonst sehr vermisse. Da ich mich in erster Linie mit Design und Frontends beschäftige, ist mein Blick darauf sehr stark geprägt durch die Brille der User Experience und des UI Designs. Schon die Gestaltung der Fehlermeldung ist in dieser Hinsicht wirklich problematisch. In meinem Alltag nutze ich auf meinem Smartphone etwa 150 Apps und bin ständig auf der Suche nach Neuem, doch keine davon benötigt einen Screen Lock mit Pattern, PIN oder Password. Ich kann mich erinnern, dass die Diskussion um Screen Lock Requirements bei Apps vor etlichen Jahren in der Developer Community schonmal Thema war und bei der ein oder anderen App angewandt worden ist. Inzwischen gibt es auf dem Markt aber quasi keine Apps mehr mit dieser Anforderung. Denn die Daten lassen sich auch ohne eine Geräteübergreifende Bildschirmsperre schützen wie auch Banking-Apps zeigen und ohne die UX zu beschädigen

@fodinabor ja, das ist ein guter Einwand! +1

Ist bei uns auch so. Nur das Sekretariat darf Personendatensätze anlegen und tut dieses nur, wenn eine entsprechende Einwilligung vorliegt.

Servus zusammen. Ich hab gute Nachrichten: das Feature wurde umgesetzt. Der Admin bekommt jetzt eine Nachricht.
https://intern.church.tools/?q=churchwiki#/WikiView/filterWikicategory_id:0/doc:Changelog-3.0/

vielen Dank Jakob für das super Feedback! Unsere Teams freuen sich schon darauf.

Die Einwilligung durch Betreuer ist wirklich ein spezieller Fall, den wir wirklich nicht abdecken in ChurchTools. Ich nehm das aber gerne mal in unser Team und dann entscheiden wir, ob wir das umsetzen wollen. Danke für den Hinweis.

Wie @hbuerger geschrieben hat hängt das mit dem Superadmin zusammen.

Wenn ihr Selfhoster seit könnt ihr diese Datei selbst anpassen.

Wenn ihr bei uns hostet könnt ihr einfach eine E-Mail an den support schicken. (support@churchtools.de)
Der kann auch die Superadmins anpassen.

Hallo,

Es lässt sich auch einstellen dass Personen nach dem ersten Login eine Verschwiegenheitserklärung akzeptieren müssen:

Admin-Einstellungen -> Datenschutz/Sicherheit -> Personen müssen nach dem Anmelden einmalig die Verpflichtung auf Vertraulichkeit und Verschwiegenheit akzeptieren.

Gruß Daniel

@alexander-w sagte in DSVGO-Dschungel:

In unserem Verband füllt man einen Mitgliedsantrag aus, auf dem folgenden Satz unterschriebt: "Ich bin mit der elektronischen Erfassung meiner Daten für vereinsinterne Zwecke einverstanden."

Dann müsste es ja passen, dass wir diese Person in churchtools auflisten. Oder müsste man nochmal allen Mitgliedern nachgehen, den Satz umändern lassen und unterschreiben lassen, dass man nun einverstanden ist, dass man die Daten nach der "neuen DSVGO" akzeptiert?

Die einmalige, ausdrückliche Einwilligung reicht da vollkommen aus. Wobei die betreffende Person eigentlich im Zuge der Einwilligung über ihre Rechte aufgeklärt werden sollte/muss... D.h., dass bei diesem Satz auch noch mal stehen müsste, dass man jederzeit verlangen darf, die Daten zu löschen oder zu aktualisieren, dass man die Einwilligung widerrufen kann usw. (https://www.datenschutz.org/einwilligungserklaerung/)

Macht ja meiner Meinung nach keinen Unterschied in der Art und Weise, wie wir die Daten behandeln. Man muss ja immer darauf achten, dass man Daten nicht weitergibt. Vor und nach DSVGO.

"Weitergeben" kann eine von vielen unrechtmäßigen Arten von Datenverarbeitung sein. Und wenn ihr Hosting-Kunden bei ChurchTools seid, dann gebt ihr die Daten sogar weiter... Um das problemlos machen zu können bietet die ChurchTools Inovations GmbH, mit ihren Kunden einen Auftragsverarbeiter-Vertrag abzuschließen. Im Grunde verpflichtet der ChurchTools dazu, sich an die strengen Datenschutzbestimmungen ihrer Kunden zu halten und nimmt damit einen Teil des Haftungsrisikos auf sich (so ungefähr).

Ich verstehe die ganze Aufregung nicht. Ob vor oder nach der DSVGO. Vor allem in Gemeinden - keiner gibt doch einfach so Daten raus.

Im Prinzip hast du völlig Recht. So grundlegend hat sich mit der DSVGO für pflichtbewusste Verarbeiter von personenbezogenen Daten nichts verändert. Ein wenig mehr Dokumentationspflicht bei den verarbeitenden Stellen und Auskunftsrecht bei betreffenden Personen...

Ich hatte hier mal eine Übersicht zum Thema DSVGO gepostet, die ich selbst recht hilfreich fand.

Danke für die Anregungen, aber wir haben uns dagegen entschieden. Es soll ruhig über den Schreibtisch eines dafür vorgesehen Mitarbeiters gehen. Wie @hbuerger schon richtig schreibt, ist es nicht Pflicht, dass der User es selber machen können muss.

Ich möchte gerne eine Idee in den Ring werfen, die wir wohl umsetzen werden:

Ich habe die betreffenden DB-Felder des Sicherheitslevel 1 (z.B. Telefon privat und Handy) dupliziert und diesen das Sicherheitslevel 2 zugeordnet. Widerspricht jetzt jemand der Weitergabe der Kontaktdaten an andere Mitarbeiter der Dienstgruppen, werden die Daten in die Felder mit dem höheren Sicherheitslevel eingetragen.

Wie wir die Verweigerung der Einwilligung dokumentieren und alle Mitarbeiter, die Personen in ChurchTools erstellen dürfen, schulen, steht auf einem anderen Blatt Papier 🙈

@a-zwinkau

Hi Anne, aus gegebenen Anlass.

Könnt ihr es intern vielleicht noch einmal diskutieren, ob es tatsächlich Sinn macht, dass der Einteiler auf alle Personen zugreifen kann?

Genau das macht aus meiner Sicht keinen Sinn!
Hier sieht man, wie es gerade im Bezug auf mehrere Stationen sinnvoll wäre, wenn man das trennen könnte.
Eigene Dienste je Station sind hier schlicht und ergreifend keine Alternative - das würde bedeuten, dass ich bei 10 Stationen, 10 mal den Dienst "Gitarre" anlege.

Da ich in der Datenbank über verschiedene Rollen oder auch die Über- und Unterordnung sehr gut regeln kann, welche Gruppen eine Person sehen kann, ließe sich das auch für den Dienstplan super steuern, wenn ich will, dass eine Person hier mehrere Gruppen in der Einteilung berücksichtigen kann.

Würde mich also freuen, wenn ich das noch einmal zur Debatte stellt!

@Gunnar 😃 du bist gut drauf Gunnar 🙂

Ja, tatsächlich stoß ich bei bei der PLZ auch an meine Grenzen, ob noch erlaubt oder nicht. Hab hier noch keine abschließende DS Prüfung vorliegen. Vielleicht weiß hier jemand mehr.

Das mit dem Geburtstag ist ein guter Punkt. Darauf bin ich noch nicht gekommen 😁 sollten wir auch aufnehmen.

Und ja, Lizenzen könnten relevant sein, oder auch nicht... wer weiß das schon 😉

Wie du sagst, eine Frage der Methodik. Ich würde mich freuen, wenn CT das Reporting-Tool ist. Gibt ja sogar ein Modul dafür. Das ergibt aber nur Sinn, wenn die (nicht Personenbezogenen) Daten nicht einfach gelöscht werden

Mir geht es nicht drum persönliche Daten zu horten. Im Gegenteil. Ich will Ordnung in der Datenbank und löschen wo geht, aber eben nicht 0 oder 1, sondern irgendwie dazwischen

Ja das ist ein spannendes Thema.
Da könnte man mal tiefer ein steigen.

Vor allem den Status bei Personen (automatisch) zu wechseln, sobald sie sich das erste mal eingelogt haben. So haben sie den Datenschutzbestimmungen zugestimmt und vorher kann man sie vor den anderen "verstecken".
Aber ich mach da morgen mal einen neuen Thread zu auf. 🙂