Newsletter An- und Abmeldemodul für Wordpress
-
@bwl21 sagte in Newsletter An- und Abmeldemodul für Wordpress:
Danke dir für dein Feedback!
Bei mehreren Personen könntest du ja einfach mehrere Token erstellen und anzeigen, dann mit Name/Vorname
Das ist eine gute Idee. Dann spart man sich unter umständen eine Formular-Auswahl.
Risiko: Das Anmeldemodul muss über einen Account mit einigen Berechtigungen in CT arbeiten ...
Das stimmt - aber anders geht es nicht. Denn ChurchTools stellt diese Funktionalität bisher nicht nativ zur Verfügung. Der Nutzer braucht Lesezugriff auf die Felder Vorname, Nachname, E-Mail und die Newslettergruppen. Und Schreibzugriff auf die Newslettergruppen
Den Fall dass zu einer email mehr als eine Person gehört, (an sich ein Übel, wenn auch schwer auszurotten) könntest du dadurch abdecken, dass in der Bestätigungsmail einfach zwei Links drin sind mit zwei verschiedenen Token.
Faktisch haben wir das sogar ziemlich oft. Gerade bei Kindern, Ehepaaren und Großeltern.
Irgendwo musst du ja das Token speichern. Da könntest du eine Gruppe machen, und dort ein Gruppenfeld mit dem Token und einem Verfallsdatum.
Da das Token keine Relevanz für das CT-System als solches hat, bisher über die API keine passenden Tokens erstellt werden können und zusätzliche Gruppenfelder nur die Kompleixität erhöhen, würde ich das Token gerne im Wordpress-Plugin handhaben.
Das Verfallsdatum könntest du in das Token codieren (JWT)
Gute Idee
Die Frage ist ja, ob du Vorname-Nachname wirklich brauchst.
Wir möchten es drin haben. Denn A) will ich wissen, wer den Newsletter bekommt und B ) haben wir Newsletter, die erst "freigeschaltet" werden müssen. Außerdem verhindert es doppelte Personeneinträge, die ChurchTools ja über Vorname, Nachname und E-Mail abgleicht.
-
@skipy sagte in Newsletter An- und Abmeldemodul für Wordpress:
@bwl21 sagte in Newsletter An- und Abmeldemodul für Wordpress:
Danke dir für dein Feedback!
bitte dafür ist ein Forum da
Risiko: Das Anmeldemodul muss über einen Account mit einigen Berechtigungen in CT arbeiten ...
Das stimmt - aber anders geht es nicht. Denn ChurchTools stellt diese Funktionalität bisher nicht nativ zur Verfügung. Der Nutzer braucht Lesezugriff auf die Felder Vorname, Nachname, E-Mail und die Newslettergruppen. Und Schreibzugriff auf die Newslettergruppen
Ja, ich sehe da auch keine andere Möglichkeit, ich wollte nur auf das Risiko hinweisen. du kannst ja einen eigenen account dafür nehmen, mit den und nur den Zugriffrechten, die er wirklich braucht.
Den Fall dass zu einer email mehr als eine Person gehört, (an sich ein Übel, wenn auch schwer auszurotten) könntest du dadurch abdecken, dass in der Bestätigungsmail einfach zwei Links drin sind mit zwei verschiedenen Token.
Faktisch haben wir das sogar ziemlich oft. Gerade bei Kindern, Ehepaaren und Großeltern.
Das macht es leider nicht besser. Bei Kindern die E-Mail der Eltern anzugeben finde ich ziemlich unglücklich, es gibt ja das Beziehungsfilter.
Für mich ist email klar personenbezogen.
Irgendwo musst du ja das Token speichern. Da könntest du eine Gruppe machen, und dort ein Gruppenfeld mit dem Token und einem Verfallsdatum.
Da das Token keine Relevanz für das CT-System als solches hat, bisher über die API keine passenden Tokens erstellt werden können und zusätzliche Gruppenfelder nur die Kompleixität erhöhen, würde ich das Token gerne im Wordpress-Plugin handhaben.
Das würde ich nicht machen, denn dann dadurch hast du eine Abhängigkeit zu Wordpress (also nicht mehr CMS-agnostisch). Das würde ich dann eher einfach in ein PHP-Objekt serialisieren, die leben ja nicht lange. Da könntest du sogar das Token als Filename nutzen ... Das wäre sogar einfacher als die Sache mit dem Gruppenfeld.
Gruppenfeld hätte aber den Vorteil, dass ein Admin die zur Zeit "offenen" Token in CT nachschauen, und ggf. auch löschen kann.
Die Frage ist ja, ob du Vorname-Nachname wirklich brauchst.
Wir möchten es drin haben. Denn A) will ich wissen, wer den Newsletter bekommt und B ) haben wir Newsletter, die erst "freigeschaltet" werden müssen. Außerdem verhindert es doppelte Personeneinträge, die ChurchTools ja über Vorname, Nachname und E-Mail abgleicht.
Doppelte Personeneinträge musst du in "Modul" vermeiden. Aber es ist richtig, bei neu anlegen einer Person solltest du Vor/Nachname haben - aber du kannst nicht vermeiden, dass du eine Meng fake-Vornamen bekommst.
Ich erlaube mir noch einen Hinweis auf https://forum.church.tools/topic/7200/ann-helper-für-den-zugriff-via-api?_ zur einfachen Handhabung der API
-
Ich erlaube mir noch einen Hinweis auf https://forum.church.tools/topic/7200/ann-helper-für-den-zugriff-via-api?_ zur einfachen Handhabung der API
Nice
- ich hab mir allerdings schon einen eigenen Swagger-Wrapper vor einiger Zeit geschrieben, dass ich sehr leicht auf die neuen API-Versionen aktualisieren kann. Das Vineyard Repo war für meine Zwecke leider schon einige API-Versionen zu weit hintendran. 
Noch schöner wäre es natürlich, wenn ChurchTools uns da direkt ein Composer-Package zur Verfügung stellen würde ...
-
@skipy ok, wollte es nur anbieten. Damit schreibe ich mein Scripte, die gegen die CT-API laufen. Da brauche ich nicht nochmal einen extra Wrapper drum rum, sondern kann die CT-Doku direkt umsetzen. Den Vinyard wrapper hatte ich auch gesehen, aber das ist ja wieder ein extra API.
Mit der Methode kann ich ganz schnell gegen das API programmieren, und kann mir natürlich immer noch helper dazu bauen, wenn ich sie brauche (habe ich auch, z.B. um paginierungen zu lesen).
Der Nachteil meiner Methode ist natürlich, dass ich bei Anpassungen der API seitens CT alles Anwendungen adaptieren muss. Da CT das aber auch muss, hoffe ich, dass sich das in Grenzen hält.
-
Könnte sich noch jemand direkt von ChurchTools zu dem Thema äußern? (Exemplarisch mal @davidschilling, @hbuerger)
- Macht der Workflow Sinn? Was fehlt?
- Arbeitet ihr an etw. ähnlichem, so dass die Geschichte hier kontraproduktiv ist?
-
Ein paar Gedanken dazu.
Ich würde denken, dass ChurchTools die meisten deiner Anforderungen schon abdeckt.
Eine einfache Möglichkeit, dass sich neue Leute für einen oder mehrere Newsletter registrieren können (ggf. via öffentliche Gruppen realisierbar)
Das ist ein perfekter Anwendungsfall für die Gruppenhomepage
Eine Möglichkeit, dass sich (auch nicht CT-Nutzer) einfach eine Übersicht über ihre bereits abonierten Newsletter bekommen.
Das fehlt noch fände ich aber generell eine sinnvolle Erweiterung für ChurchTools.
Eine Möglichkeit, dass sich (auch nicht CT-Nutzer) DSGVO Konform von Newslettern abmelden können.
Das ist aktuell möglich über den Abmeldelink den man in der ersten Mail nach der Anmeldung in einer öffentlichen Gruppe bekommt.
- Ich denke du könntest deine Anforderungen mit ChurchTools umsetzen auch wenn es nicht ganz perfekt ist.
- Dein vorgeschlagenes Konzept sollte aus meiner Sicht funktionieren. Ich sehe jetzt keinen Punkt der hier groß problematisch ist.
- Generell musst du halt abwägen wie viel dir deine "bessere" Lösung Wert ist, da schon ne Menge Aufwand dahinter stecken wird. Aber ich will dich auch nicht davon abhalten. Ich freue mich wenn die ChurchTools Api verwendet wird. Dafür bauen wir sie ja.
-
Danke @davidschilling für deine Rückmeldung. Die ist sehr willkommen.
Eine Möglichkeit, dass sich (auch nicht CT-Nutzer) DSGVO Konform von Newslettern abmelden können.
Das ist aktuell möglich über den Abmeldelink den man in der ersten Mail nach der Anmeldung in einer öffentlichen Gruppe bekommt.
Leider ist genau das gerade eben unser Hauptproblem. Der aktuelle Weg, wie ChurchTools E-Mails verschickt ist eben nicht DSGVO konform. Denn wenn ich die DSGVO richtig verstehe, muss eine "Abmeldung vom Newsletter jederzeit möglich sein".
Hier einige konkrete Beispiele, die eben nicht funktionieren:
- Ein Nutzer hat die erhaltene Gruppenanmelde-EMail gelöscht
- Die Anmeldung in einer Gruppe liegt viele Wochen zurück und ein Nutzer findet seine Anmelde-EMail nicht mehr
- Ein Nutzer hat sich bei mehreren Newslettern der Gemeinde (aka Gruppen) registriert. Er will sich jetzt nur (!) von einem abmelden. Aber wenn es nicht explizit in der E-Mail erwähnt ist, findet er nicht heraus, über welchen Gruppenverteiler eine Mail verschickt wurde und kann sich dementsprechend auch nicht abmelden.
Laut DSGVO muss eine Abmeldung auch dann möglich sein, wenn der E-Mail-Support (z.B. am Wochenende) nicht zur Verfügung steht. Es braucht also eine technische Lösung. Derzeit bietet Churchtools meines Wissens allerdings keine Möglichkeit für Nicht-Churchtools-Nutzer sich jederzeit wieder abzumelden.
Als Defakto-Standard hat es sich bei Newslettersystemen eingebürgert, dass man im Footer einer erhaltenen E-Mail individuell generierten Hash eingebettet bekommt, der einen zur individualisierten "Abmelde-Homepage" führt. Somit kann er sich jederzeit von seinem Newsletter abmelden. Eine solche Möglichkeit würde ich unbedingt vorziehen, aber ist bisher in ChurchTools nicht vorhanden. Wenn so etwas in nächster Zeit geplant ist, wäre mir das viel (!) lieber, als es selbst programmieren zu müssen.
Die Lösung mit einer zentralen Webseite, wo alle öffentlichen Newsletter einer Person einsehbar und veränderbar sind, ist nur ein Workaround. Lieber wäre es mir, das in CT von Haus aus machen zu können.
-
@skipy hallo, hast du an der Sache eigentlich weiter gemacht? Ich kommen an der sache auch wieder vorbei, und denke darüber nach, die Abmeldung einfach über eine Anmeldung an einer Abgemeldet-Gruppe zu realisieren.
Dann könnte man sich sofort abmelden. Die Umsetzung wäre dann so, dass man vor dem Versand an eine Verteilerliste, erst mal die Abmeldungen rausnimmt.
Alles ein bisschen Workaround, zugegeben ...
-
@bwl21 Ja, wir haben das ganze als Gutenberg (Wordpress-Block) Modul fertig programmiert und es ist bei uns im Einsatz.
Falls du es ausprobieren möchtest:
https://plugins.sv-schoenaich.de/?action=download&slug=sb-churchtools-grouphomepageEs ist allerdings noch nicht alles ganz fertig dokumentiert. Vergiss nicht im Backend den API-Nutzer zu konfigurieren ... Der Nutzer braucht Zugriffsrechte auf die entsprechenden Gruppen und (falls auch Neuanmeldungen möglich sein sollen) auf alle Personen, die erkannt werden sollen.
Wenn du Fragen hast, meld dich gern ... -
Hier noch ein paar Screenshots dazu
-
@skipy Die Screenshots sehen gut aus.
Leider ist es nicht CMS-unabhängig, daher passt es für uns nicht so recht (wir sind in Contao).
lässt sich die Logik vom UI trennen, so dass ich in Contao ein andres UI drüber legen kann?
-
@bwl21 Sollte weitestgehend möglich sein. Gibt ne ServiceKlasse.
Die UI ist ebenfalls komplett losgelöst von Gutenberg verwendbar und kann theoretisch als UI Komponente eingebunden werden. (under the hood ist es vuejs)
Ergänzung:
Mir kommt gerade, es gibt ein-zwei Sicherheitsaspekte in Bezug auf Tokens, die im Backend-Controller gehandhabt werden - da ist teilweise die UI mit verknüpft. Das müsste entsprechend bei einem eigenen Frontend nachempfunden werden. -
@skipy könntest du ein git repo aufsetzen bei dem die Service, Backend, ui und CMS Integration getrennt sind? Ich könnte dann eine contao Integration beisteuern.
-
@bwl21 Kann ich gerne versuchen ... jetzt im Herbst ist bei uns aber gerade volles Programm - da werde ich das nicht schaffen
