QFQ

Gespeichert wird ueber eine API, diese benoetigt keine Typo3 Session.

Weitergeleitet wird nach der Antwort von der API - warum er dann auch auf eine Login Seite kam und entsprechend nichts von der Forward Seite ausgefuehrt wurde.

Das Frontend Login laeuft nach 24h ab, nach maxLifetime - was durchaus moeglich ist, falls sie ihren Computer nur in den Sleep Modus schalten und nicht herunterfahren.

Generell kann man das Problem ganz vermeiden, wenn du das Update und den Mail versand direkt im Formular ueber Actions ausfuehrst. Falls irgendwie moeglich waere also das zu empfehlen.

Vielen Dank für die Antwort.

Wie das Log zeigt, waren zwischen Login und speichern nur 4h. Das sollte eigentlich klar unter den lifetime settings sein...

Betreffend Action Elementen: Ich versuche die möglichst zu vermeiden. Die sind viel weniger flexibel und verständlich als ein normaler Report [1]. Entspechend ist das für uns keine Lösung. Eine möglicher Hack wäre aber wohl eine Datenfeld mit Timestamp und eine BeforeSave-Action, die den Save blockiert, falls zu viel Zeit verstrichen ist.
Statt ein solches Konstrukt in jedes Formular einzubauen, fände ich es aber natürlich sinnvoller, wenn beim Formular konfiguriert werden könnte, dass die API eine FE-Session verlangen soll.
Allzu dringend ist das Problem aber noch nicht, so häufig scheint das nicht aufzutreten.

[1] Dinge die ich als Nachteile der Action sehe:
- Action mit mehreren, von einander abhängenden Queries über verschiedene Tabellen sind unmöglich/unverständlich.
- keine Versionierung
- ich kann ein Action-Element nicht in einem anderen Formular wiederverwenden

Das betrofene Report-Element sieht so aus

10.sql = SELECT firstname AS _firstname, name AS _name, mail_uzh AS _mail, shortname AS _shortname, colloquium_start AS _colst, disputation_start AS _dispst, colloquium_duration AS _coldur, disputation_duration AS _dispdur, colloquium_place AS _colpl, disputation_place AS _disppl 
FROM phd_graduation 
WHERE id='{{r:SE}}' AND check_head_done IS NOT NULL AND reg_mails=1

10.2.sql = SELECT 't:{{mail:R::s}}|f:{{phd_from_email:UE}}|s:Registration for Graduation Confirmed|b:
Dear {{firstname:R::s}} {{name:R::s}}\n
\n
The head of your PhD committee confirmed your registration.\n
\n
Your defense is scheduled as follows:\n
\ \ colloquium start:\ \ \ \ \ {{colst:R::s}}\n
\ \ colloquium duration:\ \ {{coldur:R::s}}\n
\ \ colloquium place:\ \ \ \ \ {{colpl:R::s}}\n
\ \ disputation start:\ \ \ \ {{dispst:R::s}}\n
\ \ disputation duration:\ {{dispdur:R::s}}\n
\ \ disputation place:\ \ \ \ {{disppl:R::s}}\n
\n
As a next step you now need to visit the Office of Student Affairs no later than 4 weeks before the defense and bring the following documents:\n
\ \ - two copies of your dissertation’s title page\n
\ \ - a copy of your passport/id-card\n
\n
best wishes\n
Office of Student Affairs
' AS _sendmail

10.3.sql = UPDATE phd_graduation SET reg_mails=2  WHERE id='{{r:SE}}'

10.10.sql = UPDATE `phd_milestones` SET 
confirmed=NOW(), confirmed_by='{{feUser:TE}}'
WHERE type=7 AND student='{{shortname:RE}}'

Hallo Nicola

Session Timeout
---------------

• FE Login: Wir haben eine T3 Instanz bei der wir schnell ausgeloggt werden (30mins). Andere T3 Instanzen auf dem gleichen Server haben 24h. Erklaerung: Keine.

Formular speichern, Mails versenden, Records aktualisieren
----------------------------------------------------------

• Ein Unterbruch in dieser Kette kennen wir nicht, da wir alles in einem Form machen (und kein Report nutzen).
• Mittlerweile geht das sogar in einem einzigen FormElement.type=sendmail (alles an einem Ort: Parameter.sqlBefore|sqlAfter).
• Formulare mit Versionierung: #9602

CU
Carsten

Carsten Rose wrote:

• FE Login: Wir haben eine T3 Instanz bei der wir schnell ausgeloggt werden (30mins). Andere T3 Instanzen auf dem gleichen Server haben 24h. Erklaerung: Keine.

Ok. Dann investiere ich da für den Moment auch nicht mehr Zeit...

Formular speichern, Mails versenden, Records aktualisieren
----------------------------------------------------------

• Ein Unterbruch in dieser Kette kennen wir nicht, da wir alles in einem Form machen (und kein Report nutzen).

Ok.

• Mittlerweile geht das sogar in einem einzigen FormElement.type=sendmail (alles an einem Ort: Parameter.sqlBefore|sqlAfter).

Das tönt spannend. Kannst du mir ein Beispiel senden (oder gleich mein Beispiel in Parameter.sql* umbauen)?

Allgemeine Absender hinterlegen wir zentral in der QFQ Config, in Deinem Fall koennte das sein: '{{phd_from_email:Y}}'.

FormElement:

Ttitle: sendmail: registration confirmation
Typ: sendmail
Value:
------------------------------------------------------------------
Dear {{firstname:V::s}} {{name:V::s}}

The head of your PhD committee confirmed your registration.

Your defense is scheduled as follows:
  colloquium start:     {{colloquium_start:V::s}}
  colloquium duration:  {{colloquium_duration:V::s}}
  colloquium place:     {{colloquium_place:V::s}}
  disputation start:    {{disputation_start:V::s}}
  disputation duration: {{disputation_duration:V::s}}
  disputation place:    {{disputation_place:V::s}}

As a next step you now need to visit the Office of Student Affairs no later than 4 weeks before the defense and bring the following documents:
  - two copies of your dissertation’s title page
  - a copy of your passport/id-card

best wishes
Office of Student Affairs
------------------------------------------------------------------

Parameter:
------------------------------------------------------------------
fillStoreVar={{! SELECT firstname, name, mail_uzh, shortname, colloquium_start, disputation_start, colloquium_duration, disputation_duration, colloquium_place, disputation_place
FROM phd_graduation 
WHERE id='{{id:R0}}' AND check_head_done IS NOT NULL AND reg_mails=1 }}

sendMailTo={{mail_uzh:V::s}}
sendMailSubject=Registration for Graduation Confirmed
sendMailFrom = {{phd_from_email:Y}}

sqlBefore = {{UPDATE phd_graduation SET reg_mails=2  WHERE id='{{id:R0}}'}}
sqlAfter = {{UPDATE `phd_milestones` SET confirmed=NOW(), confirmed_by='{{feUser:TE}}' WHERE type=7 AND student='{{shortname:VE}}'}}
------------------------------------------------------------------

Hoi Carsten

Vielen Dank für deine ausführliche Antwort. Habe das eben endlich ausprobiert und das funktionert im Allgemeinen sehr gut. Ein paar Anmerkungen/Fragen:

• Wir benutzen qfq config nicht for Konfiurations-Variablen stattdessen sind die bei uns in einer DB-Tabelle und werden beim Login geladen mit:
  

  
  1.sql = SELECT label FROM _constants
  1.content = hide
  1.1.sql = SELECT value AS '_={{label:R}}' FROM _constants WHERE label='{{label:R}}'
  

• Auch das ursprüngliche Formular des Studenten funktioniert analog, das muss aber auch vor dem finalen Submit zwischengespeichert werden können. Dann darf das Mail natürlich nicht ausgelöst werden. Könnte ich das mit einem sendMail-Element auch lösen?

• Für mich ist nicht offensichtlich wann welches der Queries in Parameter ausgeführt wird. (sqlBefore wird offensichtlich nach fillStoreVar und fillStoreVar wird erst während dem Speichern und nicht während dem Laden ausgeführt) Das macht diese Methode deutlich weniger verständlich als die Report-Syntax. (Und im Gegensatz zur Report Syntax, sind die Queries jetzt auch nicht von einander abhänig. Das sqlBefor-Query wird also wohl auch ausgeführt, wenn etwas beim Mail-Versand schief geht. Auch das ist ein kleiner nachteil)

• Schliesslich nicht direkt mit dem verknüft: Kann ich die Font-Family der Text-Area irgendwo einfach auf monospace auf ändern?