mailSchedule und mailRevoke auf einer Seite

Question

Liebes Supportteam,

ich habe die folgenden Befehle auf einer Seite stehen:

mailRevoke (false, 36); //Versand Abschlussfragebogen canceln
mailRevoke (false, 37); //Erinnerungsmail Abschlussfragebogen canceln
mailSchedule (false, 36, $beratungsstunde+604800); //Versand Abschlussfragebogen eine 7 Tage nach nächster Stunde festsetzen
mailSchedule (false, 37, $beratungsstunde+864000); //Versand Erinnerung Abschlussfragebogen 10 Tage nach nächster Stunde festsetzen

Damit soll ein vorher festgelegter Versandzeitpunkt für den Abschlussfragebogen gelöscht und ein neuer in Abhängigkeit der vom Probanden gemachten Angabe (Variable $beratungsstunde) festgelegt werden.

Allerdings scheinen einige Probanden den Link zum Abschlussfragebogen nicht zu erhalten.

1) Ist irgendetwas mit dem Code falsch?

2) Müssen die Probanden auf weiter klicken, damit der Code ausgeführt wird oder werden die Befehle ausgeführt, sobald ein Proband auf diese Seite gelangt?

Beste Grüße und vielen Dank für die Unterstützung

Answer 1

ad 1) Ich sehe spontan keinen offensichtlichen Fehler - aber Sie sollten es einmal mit Ihrer eigenen Mailadresse testen und dann prüfen, was bei Ihrer Mailadresse in der Adressliste als Versandzeitpunkt angezeigt wird. Womöglich ist der Inhalt der Variable $beratungsstunde nicht korrekt.

ad 2) Der Code wird direkt beim Aufruf der Seite ausgeführt und damit aktiv - ein "Weiter" ist nicht notwendig.

Ob ein mailRevoke(), das direkt von einem mailSchedule() gefolgt wird, Probleme macht, habe ich ehrlich gesagt noch nicht ausprobiert. Es sollte funktionieren - aber prinzipiell können Sie auch unterschiedliche Kopien der Serienmail canceln und neu terminieren. Aber wie gesagt: Ich glaube nicht, dass das Problem hier liegt.

Comments

Ich habe nun eine mögliche Fehlerquelle entdeckt:  Die Probanden geben in drei verschiedenen Textfeldern an, an welchem Tag('O120_01'), in welchem Monat ('O120_02') und zu welcher Stunde ('O120_03') ihre Beratung stattfindet. Diesen Angaben entsprechend, wird dann der Zeitpunkt zum Versand des Abschlussfragebogens wie oben beschrieben angepasst. Der Code zur Definition der Variable $beratungsstunde, die den Zeitpunkt enthält, sieht wie folgt aus:

$datum = array (value ('O120_01'), value ('O120_02'), 2018);
$uhrzeit = value('O120_03');
$beratungsstunde = array (implode ('.', $datum), $uhrzeit);
$beratungsstunde = implode ('', $beratungsstunde);

$beratungsstunde = strtotime ($beratungsstunde);

//Mail zum nächsten Fragebogen wird sofort geschickt
mailSchedule(false, 18, 1);

//Erinnerung wird halbe Stunde vor geplantem Termin geschickt
mailSchedule(false, 19, $beratungsstunde-1800);

mailRevoke (false, 36); //Versand Abschlussfragebogen canceln
mailRevoke (false, 37); //Erinnerungsmail Abschlussfragebogen canceln
mailSchedule (false, 36, $beratungsstunde+604800); //Versand Abschlussfragebogen 7 Tage nach nächster Stunde festsetzen
mailSchedule (false, 37, $beratungsstunde+864000); //Versand Erinnerung Abschlussfragebogen 10 Tage nach nächster Stunde festsetzen

Wenn nun eine Person ein nicht existierendes Datum (z.B. den 32. September, also O120_01 == 32 und  O120_02 == 09) eingibt, wird die Einladung zum Abschlussfragebogen zwar gelöscht, aber keine neue mehr festgelegt, scheinbar aufgrund des falschen Datums.

Können Sie mir sagen, wie ich die Eingabe nur auf realistische Werte beschränken kann?
Ich habe etwas von Perl-Regeln gelesen, habe aber keinen Schimmer wie diese funktionieren. Ich würde das Item "Tag"/O120_01 gerne auf 01-31 beschränken, das Item "Monat"/O120_02 auf 01-12 und das Item "Uhrzeit"/O120_03 auf 0800-2100.

Am besten wäre "Tag" in Monaten mit nur 30 Tagen auch nur auf 01-30 beschränkt. Ist das möglich?

---

seltsamerweise funktioniert es aber auch nicht, wenn ich den 30. September um 13Uhr eingebe, sprich:

O120_01 == 30
O120_02 == 09
O120_03 == 1300

---

Ich würde nicht unterschreiben, dass strtotime() mit einer Zeitangabe 1300 zurecht kommt. Aber das können Sie einfach testen. Ergänzen Sie unter

> $beratungsstunde2 = strtotime ($beratungsstunde);

(Name der ersten Variable geändert!)

Bitte folgendes:

debug($beratungsstunde);
debug($beratungsstunde2);
debug(date('d.m.Y H:i', $beratungsstunde2));

Das sollte das Problem eingrenzen.

---

Danke für die Antwort. Wenn man das ergänzt kommt in den Debuginformationen alles wie erwartet raus (ich habe den 30. September um 13Uhr als Datum angegeben), allerdings wird keine Serienmail vorbereitet...komisch.

Hier die Debug-Informationen:

Hinweis (Seite 3)
Debug-Information für $beratungsstunde:
$beratungsstunde = 30.09.201813:00 (string)

Hinweis (Seite 3)
Debug-Information für $beratungsstunde2:
$beratungsstunde2 = 1538305200 (integer)

Hinweis (Seite 3)
Debug-Information für date('d.m.Y H:i', $beratungsstunde2):
date('d.m.Y H:i', $beratungsstunde2) = 30.09.2018 13:00 (string)

---

Wurde das Interview im Rahmen einer Serienmail gestartet? Was sagt denn...

debug(caseSerial());

Und wenn ja: Hat diese Person diese Serienmail, die nun verschickt werden soll, schon einmal bekommen?

---

ja, das interview wurde mit einer Serienmail gestartet.

Debug-Information für caseSerial():
caseSerial() = false (boolean)

Nein, die Person hat die Serienmail, die nun verschickt werden soll, vorher noch nie bekommen.

Es ist wirklich komisch, dass wenn ich den 30. September, 13Uhr wie geschildert  angebe, keine Serienmail vorbereitet wird. Wenn ich dann auf den zurück knopf gehe und zum Beispiel den 28. September angebe, wird eine Serienmail vorbereitet (wie ich in der Liste der Serienmails sehen kann).

---

Also wenn `caseSerial()` keine Nummer liefert, dann weiß SoSci Survey nicht, wen es da vor sich hat. Auch erkennbar daran, dass die Spalte "SERIAL" im Datensatz leer ist. Mögliche Ursachen:

1. Das Interview wurde nicht via individuellem Serienmail-Link gestartet

2. Der Fragebogen ist nicht im Zugriffsmodus "Serienmail"

3. Die Adressen wurden mit dem Datenschutz-Modus "anonym" importiert, vgl. https://www.soscisurvey.de/help/doku.php/de:survey:mailing#datenschutz-modus

---

Meines Erachtens nach ist die Rückmeldung "caseSerial() = false (boolean)" im Debug Modus doch völlig normal. Das Interview wurde NCHT über einen personalisierten Link gestartet (das ist im Debug Modus gar nicht möglich, oder?).

Wenn ich es aber richtig durchteste mit meiner E-Mail Adresse und mir Links zusenden lasse funktioniert alles. Die Spalte SERIAL ist gefüllt. Daran kann es nicht liegen. Außerdem werden sie anderen Serienmails (18 und 19) ja ordnungsgemäß versandt...

---

Ja, ich wollte eigentlich schreiben html('<p>'.caseSerial().'</p>'); für die Anzeige im regulären Betrieb.

> Außerdem werden sie anderen Serienmails (18 und 19) ja ordnungsgemäß versandt...

Ich kann nicht ausschließen, dass sich das mailRevoke() mit dem mailSchedule() in die Quere kommt. Für eine sichere Antwort muss ich mal mit etwa Muse in den Quellcode sehen. Aber dann machen Sie bitte einfach Kopien der Serienmails 36 und 37 und tragen Sie diese bei mailSchedule() ein, wie in der ursprünglichen Antwort auf Ihre Frage empfohlen. Wenn es dann funktioniert, liegt es wohl daran, dass die Neu-Anlage eines Versands direkt nach dem Löschen des bereits angelegten Versands noch nicht funktioniert...

---

ich habe mittlerweile alles Erdenkliche durchgetestet und es muss etwas mit dem Zurückspringen über den Zurück-Knopf zu tun haben.

Wenn ich zunächst z.B. den 30.09. (2018) um 1300 Uhr angebe funktioniert, alles. Ich drücke auf Weiter. Auf dieser Seite stehen dann die mailSchedule und Revoke Befehle. Wenn ich dann zurück gehe, und ein andere Datum eingebe, z.B. den 18.08. (2018) um 1300Uhr, verschwindet die Mail zum 30.09. zwar, aber wird keine neue aufgesetzt.

Kann es sein, dass mailRevoke Befehle beim vor und zurück gehen immer wieder ausgeführt werden, mailSchedule Befehle hingegen nicht?

---

Ja, das könnte durchaus sein ... mailSchedule() wird (wenn ich mich korrekt erinnere) blockiert, wenn es mehrfach auf derselben Seite des Fragebogens aufgerufen wird. Ich prüfen einmal, ob das noch notwendig ist...

---

So ... nach eingehender Analyse konnten wir diese mailSchedule()-Sperre deaktivieren. Es ist zwar ein sehr spezieller Fall, denn Sie in Ihrem Fragebogen konstruiert haben - aber auch sowas sollte natürlich wie erwartet funktionieren. Danke für die eingehende Problemsuche.

---

Vielen Dank!!!!!!

Jetzt funktioniert es einwandfrei. Habe die möglichen Eingaben jetzt noch mit Perl-Regeln beschränkt (beim 32. Oktober wurde das Datum zum Versand der Serienmail zum Beispiel nicht angepasst).

Ab und zu erschien jetzt noch die Fehlermeldung:

 Fehler im Fragebogen (Seite 1)
Beim Erstellen der Fragebogen-Seite ist ein Fehler aufgetreten. Es wäre sehr freundlich, wenn Sie den Projektleiter über das Problem informieren und die Fehlermeldung unten weiterleiten. Herzlichen Dank.
Der PHP-Code hat eine Ausgabe erzeugt, obwohl er das nicht dürfte.
string(4) "TEST"

Es funktionierte trotz der Fehlermeldung alles einwandfrei. Können Sie das noch beheben?

---

Oha - da war ich wohl etwas zu schnell mit dem Hochladen der Änderungen. Das "TEST" sollte nun verschwunden sein. Entschuldigung.