Newsletter

Folgende Angaben sind Teil der Bestellung:

• Headerbild und Logo sind getrennte Grafiken und können, bei Bedarf, mit einem Partnerlogo ergänzt werden. Siehe dazu die Spezifikation in Ticket Nr. 30136. Das Bild soll im JPG-Format gespeichert werden. Die in der Kerbe verwendete Schrift ist „Söhne - Halbfett“ (@visol: Der Font ist, zusammen mit einer Musterdatei und Anleitung für Affinity Photo, im Kundenordner von Google Drive.)
• Titel des Newsletters (i.d.R. identisch mit Text auf Grafik)
• Bezeichnung des Newsletters (Text unterhalb des Headers)
• IDs der folgenden Seiten, die im für den Newsletter verantwortlichen Bereich untergebracht sein müssen: Impressum/Kontakt, Anmeldeseite. Die Seiten dürfen noch deaktiviert sein.
• Information, ob und wo (Seiten-ID) ein Newsletter-Archiv eingerichtet wird.
• Information, ob der Newsletter an interne Benutzer (siehe unten) oder externe Benutzer geht. Bei internen Benutzern die Angabe der Datenquelle (XML-Datei auf dem Server), bei externen Benutzern Info, auf welcher Seite die Anmeldung eingefügt werden soll.
• Information, ob der Newsletter öffentlich einsehbar ist oder nur von intern bzw. via SwitchAAI- oder Benutzername/Kennwort-Anmeldung.

Siehe auch https://docs.google.com/document/d/1yQUSdqJUaafySsbSkCl5olTmXOwnUrquFh-mgBdGh3Y/edit

Die Einrichtung erfolgt direkt im Backend der Live-Umgebung (https://www.unilu.ch/typo3)

• Anlegen einer neuen BE-Benutzergruppe mit dem Titel „newsletters/[newsletter-name]“. Diese Gruppe erbt die Benutzergruppe „! Newsletters: Erstellen und Versenden“. Es sind keine weiteren Einstellungen nötig.
• Hinzufügen dieser Gruppe zur Gruppe „! Newsletter: Administrator“.
• Hinzufügen dieser Gruppe zu den erlaubten Gruppen („Groups which may be assigned through the action“) in der sys_action „Backend-Benutzer verwalten“ (im Root-Verzeichnis - auf eine vernünftige alphabetische Sortierung achten).

• Anlegen eines neuen Folders mit „Contains plugin: Direct Mail“ im Folder „Newsletters“. Im TSconfig-Feld wird die entsprechende Benutzergruppe gesetzt: TCEMAIN.permissions.groupid=149. Im Reiter „Verhalten“ zudem die Newsletter-Sprache auswählen (ist relevant für die persönliche Anrede und den Abmelde-Link). Das Headerbild kann von der Uni unter dem Reiter Ressourcen ergänzt/geändert werden.
• Gibt es für den Newsletter ein Archiv, so muss in der Page TSConfig des Direct Mail-Folders für den Newsletter noch die Konfiguration hinterlegt werden, dass bei jeder Änderung an einem Newsletter der Cache des Archivs gelöscht wird: TCEMAIN.clearCacheCmd = 5514
• Falls es sich um einen internen (zugriffsgeschützen) Newsletter handelt, muss die Seite kurzfristig auf eine normale Seite geändert werden, damit die entsprechende Benutzergruppe ausgewählt werden kann. Zudem muss die Option „Extend to Subpages“ aktiviert sein, damit die Berechtigungen auch für alle Unterseiten gelten.

• Im Newsletter-Ordner wird nun ein Ordner (Contains Plugin: Website User) für die Benutzer angelegt. Das Vorgehen für den regelmässigen Import interner Benutzer (intern = User die keinen Abmeldelink haben sollen) über einen XML-Export ist weiter unten beschrieben.
• Sollen (ausschliesslich oder unter anderem) externe Benutzer den Newsletter abonnieren können, muss für diese ein separater Ordner (Contains Plugin: Website User) angelegt werden. In diesem Ordner wird im Reiter „Verhalten“ (Access) die Checkbox „Newsletter-Abmeldung erlaubt“ (Newsletter subscription cancellation allowed) gesetzt, falls Benutzer einen Abmelde-Link mit dem Newsletter erhalten sollen. Entsprechend den Vorschriften des UWG (Bundesgesetz gegen den unlauteren Wettbewerb) ist man auf der sicheren Seite, wenn man die Option des Abmeldelinks standardmässig eingeschaltet hat.
• Nun sollte ein Newsletter als Vorlage angelegt werden, ev. zusammen mit einigen Inhaltselementen.
• Eine bestehende Newsletter-Konfiguration aus dem Ordner EXT:/packages/userunilutemplate/Configuration/TypoScript/Extension/Userunilunewsletterrendering/Newsletters/ kopieren und anpassen. Die neuen Dateien in Git einchecken. Das TypoScript-File wird nun im Newsletter-Ordner im TypoScript-Setup eines neuen TypoScript Templates (+NL <Name>) referenziert. Das Headerbild wird auf dem Live-System in den Ordner fileadmin/newsletters/headerbilder hochgeladen und in den Seiteneigenschaften (Tab Ressourcen) des Newsletter-Ordners referenziert.
• Die Berechtigungen gemäss untenstehendem Eintrag setzen. Die Zuteilung der entsprechenden Newsletter-Gruppe zum Benutzer wird durch die Unilu vorgenommen.
• Je nach Abmachung mit der Unilu werden ev. noch *Empfängerlisten* eingerichtet.

Die Berechtigungen werden so gesetzt, dass

• Die Benutzer mit der Gruppe des Newsletters neue Newsletters erstellen, versenden und bestehende bearbeiten können.
• Andere Benutzer weder den Newsletter-Ordner noch den Ordner mit den Adressen sehen.
• Importierte Adressen nicht manipuliert werden können.

• Damit auch Downloads geschützt werden können, muss im Ordner protected/newsletters ein Unterordner für den neuen Newsletter erstellt werden. Dieser Ordner muss über Folder Permissions zugriffsbeschränkt werden:

• Für diesen Ordner muss anschliessend ein neuer Filemount erstellt werden, welcher der Backend-Benutzergruppe des entsprechenden Newsletters zugewiesen wird:

• In der Page TSconfig des Newsletter-Ordner muss die Benutzergruppe, die auf den Newsletter Zugriff hat, gesetzt werden. Dies, weil Direct Mail die Seite wie ein normaler Benutzer „fetcht“ und daher ebenfalls ein Login simulieren muss, damit der Newsletter sichtbar wird. Konfiguration: mod.web_modules.dmail.simulate_usergroup=1 (staff=3)

• Wird eine geschützte Newsletter-Seite aufgerufen, wird im PageNotFoundHandling (EXT:userunilutemplate) festgestellt, dass sich der Fehler lediglich auf unzureichende Rechte bezieht und nicht darauf, dass die Seite nicht gefunden wird. Daher wird auf die Login-Seite umgeleitet (ID konfiguriert in AdditionalConfiguration.php) und der Parameter ?redirect_url=pfad/zum/newsletter angehängt (d.h. es findet lediglich eine Umleitung statt, es wird kein Auth Service getriggert).
• Auf der Login-Seite (newsletters/login) wird zunächst der „IP Authentication Trigger“ aufgerufen (ein Plugin auf der entsprechenden Seite). Dieser prüft via API von EXT:aoe_ipauth, ob ein Benutzer per IP-Adresse authentifiziert werden könnte. Ist dies der Fall, macht der „IP Authentication Trigger“ eine Umleitung auf die redirect_url, hängt aber &logintype=login an. Dies triggert auf der Newsletter-Seite den Auth Service.
• Kann nicht per IP authentifiziert werden, werden dem Benutzer zwei Möglichkeiten angezeigt:
  • SwitchAAI: Ein Klick auf den Button leitet zum Shibboleth Identity Provider weiter. Bei erfolgreicher Authentifizierung wird ebenfalls auf die Newsletter-URL umgeleitet mit &logintype=login. Der Shibboleth Auth Service (EXT:shibboleth_auth) meldet den Benutzer an.
  • Frontend-Login: Ein normales Frontend-Login (EXT:felogin), welches alle Benutzer aller nicht versteckten oder geschützten Unterseiten von „Newsletters“ einloggen kann. Wichtig: Der Benutzerordner darf kein Unterordner eines geschützten Newsletter-Ordners sein, da er damit fürs Login nicht lesbar wäre. Ist das Login erfolgreich, wird ebenfalls zur redirect_url umgeleitet.
• Dateien, die zum Newsletter gehören, müssen ebenfalls geschützt sein. Daher befinden sie sich in einem nicht öffentlich sichtbaren Storage „protected“, in dessen Ordner per .htaccess „deny from all“ gesetzt ist. Die Extension EXT:fal_securedownload manipuliert die Links, sodass die Files per Push ausgeliefert werden. Diese Extension ermöglicht auch, Benutzergruppe für Dateien und Ordner nicht-öffentlicher Storages zu setzen. Werden solche Links direkt aufgerufen, z.B. aus dem versendeten Newsletter, und ist der Benutzer nicht angemeldet, wird zuerst aufs Login umgeleitet, ebenfalls mit einer redirect_url (siehe AdditionalConfiguration.php).

Empfänger*innen werden als Website-User Datensätze verwaltet, die in Unterordner des Newsletters gespeichert sind. Website-User können manuell angelegt, aus Excel-Dateien importiert oder über einen automatischen Import aus RD3 erstellt und aktualisiert werden.

Für den Versand werden die Adressen in Empfängerlisten zusammengefasst.

Interne Benutzer können über einen Scheduler Job/Command Controller importiert werden.

Dafür muss von der Uni eine Datei mit folgender Spezifikation auf dem Webserver hinterlegt werden (üblicherweise im Ordner /home/www-data/externaldata/) stehen:

<All>
	<Adressat>
		<ID>7001483</ID>
		<Anrede>Herr</Anrede>
		<Geschlecht>m</Geschlecht>
		<Name>Müller</Name>
		<Vorname>Peter<Vorname>
		<EMail>peter.mueller@unilu.ch</EMail>
		<Korrespondenzsprache>Deutsch</Korrespondenzsprache>
	</Adressat>
	<Adressat>
		<ID>7001485</ID>
		<Anrede>Frau</Anrede>
		<Geschlecht>f</Geschlecht>
		<Name>Meier</Name>
		<Vorname>Lea</Vorname>
		<EMail>lea.meier@doz.unilu.ch</EMail>
		<Korrespondenzsprache>Englisch</Korrespondenzsprache>
	</Adressat>
</All>

Um zu verifizieren, dass sich die Datei dort befindet, kann man sich via SSH mit dem Server verbinden:

ssh www-data@visol-unilu01.nine.ch
ll externaldata

Interne Benutzer (aus RD3) werden als Frontend User (Tabelle fe_users) in den angegebenen Zielordner importiert. Beim erneuten Import werden bestehende Adressen aktualisiert, überzählige gelöscht und neue hinzugefügt.

Als Excel angelieferte Daten werden über das Modul „Benutzer-Import“ eingelesen.

(Nur zugewiesene Felder werden importiert.)

Bounces werden an den Return-Path, also no_reply@unilu.ch, gesendet.

Da die Bounces mit einem leeren Envelope versendet werden, musste beim Unilu-Mailserver eine Ausnahme hinterlegt werden, damit die Bounces ankommen. Diese Ausnahme ist explizit für die Server-IP eingetragen, müsste also bei einem IP-/Server-Wechsel umgestellt werden.

in packages/userunilutemplate/Configuration/TSConfig/PageTSConfig/newsletters.tsconfig können die Antwortadressen pro Newsletter (sysfolder uid) bei Bedarf überschrieben werden.

[5738 in tree.rootLineIds]
  mod.web_modules.dmail.replyto_email = info@kolt-unilu.ch
[global]

Der Scheduler-Task, der den Versand durchführt ist im Backend „deaktiviert“. Das ist so in Ordnung. Ausgelöst wird die Durchführung durch `cron`

www-unilu@visol-unilu01:~$ crontab -e

# Direct Mail
>* * * * * command="/bin/bash -c \"php7.4 ~/releases/current/vendor/bin/typo3cms scheduler:run --task 18 --force\"" flock=~/tmp/scheduler-run-direct-mail.cron.lock monitorUrl="https://push.statuscake.com/?PK=31ca040c7c41ac2&TestID=6351373&time=\%s" ~/releases/current/lockLogMonitorCommand.sh >> ~/releases/current/logs/cronjobs/scheduler-run-direct-mail.log