[survey_ce] Umfragewerkzeug

[deerwood]

Hallo alle, Helmut,

zunächst herzlichen Dank für Deine Erweiterung, die ich gerade teste.

Wunderbar ist die Dokumentation, das war sicherlich verflixt viel Arbeit, zeigt aber, dass ein tolles Konzept hinter dieser Erweiterung steckt.

Positiv aufgefallen ist mir außerdem, dass Du offenbar den Ansatz von normalisierten Tabellen verfolgst (ich bin "klassischer" Datenbänker ).

Meine wichtigste Frage (hat wahrscheinlich auch mit dem CSV Thema oben zu tun): Ich vermisse einen Excel/CSV Export, der NICHT summarisch ist, sondern die Antworten jedes einzelnen Benutzers in einer (breiten) Tabelle ausgibt (allerdings nicht ganz so breit, wie Du oben angedeutet hast).

Habe ich da irgend etwas übersehen, oder gibt es wirklich nur einen summarischen Export?

Der Hintergrund: ich möchte eine Umfrage erstellen, in der Teilnehmer zunächst Kenndaten angeben, wie etwa die ersten 2 Ziffern ihrer PLZ, ihre bevorzugte Automarke, ihre Lieblingsfarbe usw, bis hin zur TAN oder sogar zur Mitglieds-Id. Danach folgen dann die eigentlichen Fragen.

Dann will ich später in der exportierten Tabelle sämtliche Antworten nach diesen Kenndaten sortieren/filtern können (mit Excel/OpenOffice.org Mitteln), so dass ich z.B. die Antworten aus Bayern von denen in Schleswig-Holstein unterscheiden kann, oder die, mit Lieblingsfarbe rot von denen mit Farbe grün getrennt behandeln kann. Und natürlich gibt es eigentlich auch keinen wirklichen Unterschied zwischen Kenndaten und Fragen, die Antworten jeder Frage können für statistische Zwecke interessant sein und es besteht Bedarf danach zu sortieren/filtern.

Zudem erscheint es mir so gar nicht sinnvoll, bei offenen Fragen (z.B. ein mehrzeiles Textfeld der Art "Welche Probleme hatten Sie mit unserem Produkt?") in der Zusammenfassung sämtliche mehrere hundert verschiedene Eingaben nebeneinander zu sehen, ohne die Meldung einem bestimmten Benutzer zuordnen zu können (jedenfalls für Mitglieder-Umfragen, aber auch für TAN/anonym, wenn es z.B. ein freiwilliges Feld für email gibt und das ausgefüllt wurde). So kann ich ja dem Teilnehmer an der Umfrage nicht helfen, und das nur, weil ich den Text in der Zusammenfassung nicht mehr der email zuordnen kann.

Ich hätte also gern einen "denormalisierten" Export aller Teilnehmer-Daten. Ich bin (fast) sicher, dass Du sämtliche Benutzer-Eingaben speicherst, so dass man mit einer (eventuell komplexen) SQL Abfrage meine gewünschten Ergebnisse bekommen kann? Falls ja, würde ich das Query selbst machen und hier zeigen.

Andere Wünsche: bei den "Offenen Fragen" würde ich mir zusätzliche Prüfungs-Varianten wünschen, etwa gültige email/URL ... aber das läuft auch schon wieder auf eine Einzel-Auswertung heraus.

Kann es sein, dass ich, für meine Zwecke, mit EFG besser dran bin?

Liebe Grüße, Georg

[deerwood]

Hallo Helmut, alle,

beim Test fiel mir auf, dass im kumulierten Excel-Export für Matrix-Fragen ein kleiner Fehler existiert (survey_ce Version 1.0.2):

die Überschriften der Auswahl sind nicht korrekt. In meinem Test war das eine Bewertung von 1-5:



Wie man sieht, wird aber nur die jeweils erste Überschrift ausgegeben und die 5. Überschrift in Spalte "G" fehlt in diesem Beispiel. Hier ein Patch, der das korrigieren sollte:

--- SurveyQuestionMatrix.php.ORG    2009-07-26 00:52:10.000000000 +0200
+++ SurveyQuestionMatrix.php    2009-12-22 03:01:10.473625000 +0100
@@ -134,13 +134,13 @@
             $counter = 1;
             foreach ($arrRows as $id => $rowdata)
             {
                 $acounter = 1;
                 foreach ($arrChoices as $choiceid => $choice)
                 {
-                    if ($acounter == 1) array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1 + $counter, "data" => utf8_decode($choice), "fontweight" => XLSFONT_BOLD));
+                    if ($counter == 1) array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1 + $acounter, "data" => utf8_decode($choice), "fontweight" => XLSFONT_BOLD));
                     array_push($result, array("sheetname" => $sheet,"row" => $row + $counter, "col" => 1 + $acounter, "data" => (($this->statistics['cumulated'][$counter][$acounter]) ? $this->statistics['cumulated'][$counter][$acounter] : 0), "type" => CELL_FLOAT));
                     $acounter++;
                 }
                 $counter++;
             } 

Kurz: die Variablen $counter und $acounter sind genau falsch herum eingesetzt (ich hätte die auch eher $row_counter und $col_counter genannt, dann wäre das evtl. schon früher aufgefallen).

Nach dem Patch erhalte ich:



Bitte nicht als Meckern missverstehen!

PS: in meinem Beispiel hatte ich diese Frage als "verpflichtend" markiert, allerdings die Option "weiss nicht" erlaubt. Wenn man genau hinsieht, dann bemerkt man, dass bei "Qualität" alle Werte auf 0 stehen, so als ob diese Unterfrage nicht beantwortet worden wäre. Nach kurzem Grübeln halte ich das für ein Feature: "weiss nicht" ist eben die Möglichkeit, in verpflichteten Matrix-Fragen die eine oder andere Unterfrage unbeantwortet zu lassen ... gut konzipiert, Helmut!

LG, Georg

[deerwood]

Hallo Helmut, alle,

ich bin ernsthaft an einem detaillierten Export (aka CSV, obwohl das Format damit nichts zu tun hat) interessiert. Deshalb habe ich begonnen, die survey_ce DB Tabellen (und zum Teil auch den Code) zu analysieren.

Schlechte Nachricht (für mich): mit nur SQL werden sich die survey_ce Tabellen der DB nicht auswerten lassen, weil diverse entscheidende Infos als serialisierte PHP Arrays gespeichert sind.

Dennoch, weil mir ein grafisches Datenmodell beim Denken hilft, hier meine ersten Analyse-Ergebnisse (edit: Grafik vollständig):



Beispiel: das Feld tl_survey.allowed_groups enthält ein Array von tl_member_group.id und die Relation ist, entgegen der Grafik, nicht eine 1:N sondern eine N:M Relation.

Das spart eine "komische" N:M Tabelle ein (die der "klassische" Datenbänker benutzen würde und die praktisch nur 2 Spalten mit group_id und survey_id enthielte), hat allerdings als Konsequenz, dass man nun via SQL diese N:M Beziehung nicht mehr auswerten kann, weil SQL natürlich in Abfragen keine PHP/TL un/deserialize Fähigkeiten hat.

So kann man also per SQL die Frage "Welche Mitglieder-Gruppen dürfen welche Umfragen sehen" nicht mehr beantworten ... und umgekehrt wird es auch schwierig: man muss erst alle Umfragen per SQL aus der DB holen, und dann mit einer Schleife über das Resultat laufen, deserialisieren und dann die DB für jede Umfrage erneut/einzeln nach den Mitglieder-Gruppen bemühen.

Sorry, hier meckere ich dann doch einmal (und nicht primär an survey_ce, sondern an TL und anderen CMS). Was hat all diese Programmierer bewogen, auf DB Features zu verzichten, wenn es um N:M Beziehungen geht?

Ich verstehe es nicht. Vielleicht kann mich jemand aufklären?

Zurück zum Thema: ich werde die Analyse fortsetzen mit dem Ziel, survey_ce um einen "rohen" Export zu ergänzen.

LG, Georg

[Acta]

Mal noch ne Frage zum Surver Werkzeug... Kann ich die Ergebniss auch irgendwo dartstellen? Also... ich hab z.b. ne Umfrage zur Seite erstellt... und nun die Frage ob es die Möglichkeit gibt das Momentane Ergebnis im Frontend darzustellen?

[hschottm]

Hallo Georg,

Ich hätte also gern einen "denormalisierten" Export aller Teilnehmer-Daten. Ich bin (fast) sicher, dass Du sämtliche Benutzer-Eingaben speicherst, so dass man mit einer (eventuell komplexen) SQL Abfrage meine gewünschten Ergebnisse bekommen kann? Falls ja, würde ich das Query selbst machen und hier zeigen.

den wird aus auch noch geben, ich hab's einfach nur noch nicht geschafft, neben den kumulierten Daten noch einen individuellen Export zu erstellen. Ich habe im Moment leider so viele andere Projekte, dass TYPOlight etwas hinten an steht. Aber ich werde mich da zu Beginn des neuen Jahres mal drum kümmern.

Andere Wünsche: bei den "Offenen Fragen" würde ich mir zusätzliche Prüfungs-Varianten wünschen, etwa gültige email/URL ... aber das läuft auch schon wieder auf eine Einzel-Auswertung heraus.

Das lässt sich sicherlich machen. Ich überlege mir da mal etwas.

Gruß,
Helmut

[hschottm]

Mal noch ne Frage zum Surver Werkzeug... Kann ich die Ergebniss auch irgendwo dartstellen? Also... ich hab z.b. ne Umfrage zur Seite erstellt... und nun die Frage ob es die Möglichkeit gibt das Momentane Ergebnis im Frontend darzustellen?

Nein, eine Auswertung für das Frontend gibt es nicht, das ist bei Umfragen ja eher untypisch. In diesem Fall dachte ich, dass man eher die quickpoll-Erweiterung nimmt. Aber ich kann das ja mal andenken.

Gruß,
Helmut

[hschottm]

Sorry, hier meckere ich dann doch einmal (und nicht primär an survey_ce, sondern an TL und anderen CMS). Was hat all diese Programmierer bewogen, auf DB Features zu verzichten, wenn es um N:M Beziehungen geht?

Ich verstehe es nicht. Vielleicht kann mich jemand aufklären?

Ich verstehe dich, allerdings nutze ich in dem Fall auch nur die TYPOlight-Standardfunktionen. Die Gruppenverknüpfungen werden in den ganzen Core-Modulen auch nur als serialisiertes Array gespeichert, deshalb habe ich das so übernommen, weil die dazugehörige Formularkomponente dieses Array so weiterverarbeitet. Ich denke mal, dass Leo dadurch die Anzahl der Datenbanktabellen etwas schlanker hält, weil man sonst noch eine Menge Relationentabellen bräuchte, aber natürlich hat es Nachteile, weil man eben nicht komplett auf SQL setzen kann.

LG,
Helmut

[deerwood]

Hallo Helmut, alle,

in meinen Tests bekam ich beim Excel-Export ein zermarmeltes Excel mit mehreren dieser PHP Fehlermeldungen:

Warning: Invalid argument supplied for foreach() in ..../system/modules/survey_ce/SurveyQuestionOpenended.php on line 57 

Mein Verdacht ist, dass bei offenen Fragen, die nicht Pflichtfeld sind und von keinem Teilnehmer ausgefüllt worden sind, das Array $this->statistics["answers"] garnicht gesetzt ist. Mit dem folgenden Patch habe ich das bei mir behoben:

--- SurveyQuestionOpenended.php.ORG    2009-07-26 00:52:10.000000000 +0200
+++ SurveyQuestionOpenended.php    2009-12-23 20:32:35.810000000 +0100
@@ -54,9 +54,11 @@
         $row++;
         array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 0, "data" => utf8_decode($GLOBALS['TL_LANG']['tl_survey_result']['answers']), "bgcolor" => $this->titlebgcolor, "color" => $this->titlecolor, "fontweight" => XLSFONT_BOLD));
         $col = 1;
-        foreach ($this->statistics["answers"] as $answer)
-        {
-            array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => $col++, "data" => utf8_decode($answer)));
+        if (is_array($this->statistics["answers"])) {
+            foreach ($this->statistics["answers"] as $answer)
+            {
+                array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => $col++, "data" => utf8_decode($answer)));
+            }
         }
         $row += 2;
         return $result; 

Ich bin aber nicht sicher, ob dass wirklich die richtige Massnahme ist, oder ob nicht an anderer Stelle statistics["answers"] als leeres Array initialisiert werden sollte.

Ein Wunsch wäre noch, dass das Feld "question" im Excel-Export durch strip_tags() geschickt wird. Dies Feld hat immer HTML Tags (wegen tinyMCE), die aber im Excel keinen Sinn machen. Ich werde das für mich patchen, die diffs zeige ich hier aber nicht, weil mehrere Dateien betroffen sind, jeweils in der Methode exportDataToExcel().

LG und fröhliche Weihnachten, Georg

[deerwood]

Hallo Helmut, alle,

zunächst danke, dass Du Dich auch an den detaillierten Export machen willst. Dennoch werde ich mal versuchen eine eigene Variante zu programmieren. Hintergrund: ich mache gerade eine Umfrage, die noch "zwischen den Jahren" online gehen soll und mein Kunde will die sehr schnell auch gefiltert auswerten können. Mein Plan ist, ein Erweiterungs-Modul zu survey_ce zu schreiben, das ich dann hier downloadbar machen werde. Falls ich früher fertig werde, als Du .

Ich verstehe dich .... dass Leo dadurch die Anzahl der Datenbanktabellen etwas schlanker hält, weil man sonst noch eine Menge Relationentabellen bräuchte, aber natürlich hat es Nachteile, weil man eben nicht komplett auf SQL setzen kann.

Ganz "klassisch" gäbe es tatsächlich eine Menge von komischen N:M-Hilfs-Tabellen. Eine Lösung wäre, dass man man nur eine einzige N:M-Tabelle vorhält, die neben den Spalten für die ID's von N und M auch noch Spalten für die Namen der beiden Tabellen und den Zweck der Beziehung hat. Etwa:

Primärschlüssel (und damit unique) wäre die Kombination aller 5 Spalten. Die JOIN-Bedingungen/WHERE-Klauseln wären dadurch zwar komplexer, aber man könnte mit SQL allein abfragen. Für das Beispiel oben hätte die Tabelle dann etwa Einträge der Art

<id_n>, <id_m>, 'tl_member_group', 'tl_survey', 'allowed_groups'

und die Spalte tl_survey.allowed_groups würde entfallen. Die Spalte 'purpose' ist nebenbei wirklich wichtig/notwendig, weil es zwischen je 2 Tabellen durchaus mehr als eine N:M Beziehung geben kann. Ein Beispiel wären die Tabellen 'Pilot' und 'Flugzeug', eine wichtige N:M Beziehung ist natürlich, welcher Pilot hat welches Flugzeug als Pilot geflogen, aber eine zweite denkbare N:M Beziehung wäre, welcher Pilot ist als Fluggast in welchem Flugzeug geflogen. Und wenn ich dann schon bei diesem "klassischen" Beispiel bin: man müsste auch noch zusätzliche Attribute der N:M Beziehung berücksichtigen, z.B. wäre es interessant, zu wissen, wieviele Stunden ein Pilot ein Flugzeug geflogen hat (kumuliert). Das ist ein Wert, der eben weder beim Piloten noch beim Flugzeug gespeichert werden kann, sondern eine zusätzliche Eigenschaft der N:M Beziehung. Kumulierbare Attribute könnte man als zusätzliche Spalten von tl_n_to_m führen. Wollte man aber eine Liste von Zeitpunkten aufzeichnen (Pilot startet das Flugzeug, Pilot landet das Flugzeug usw.) würde der unique PK das verhindern ... dann bräuchte man eine weitere Hilfstabelle für die Attribute und eine weitere FK Spalte in Tabelle/Index tl_n_to_m. Das wäre dann eine generische/allgemeingültige Lösung für sämtliche N:M beziehungen, die mit 2 Tabellen auskommt.

Aber es ist müßig und, wie gesagt, Off Topic, die Weichen sind längst im Vorfeld gestellt worden, ich glaube nicht, das Leo das jemals in TL einbauen würde, dann müsste soooo viel geändert werden (auch viele Erweiterungen). Ich musste das aber mal loswerden, damit Ihr seht, dass ich nicht "einfach so" meckere.

LG, frohes Fest

[deerwood]

Hallo Helmut, alle,

beim Testen bekam ich gestern diese Fehlermeldung:

Fatal error: Uncaught exception Exception with message Query error:
Column 'pin' cannot be null (
  INSERT INTO tl_survey_result
  (tstamp, pid, qid, pin, result)
  VALUES 
  (1261816786, '1', '2', NULL, 'a:2:{s:5:\"value\";s:1:\"0\";s:5:\"other\";s:0:\"\";}')
) thrown in .../system/libraries/Database.php on line 533

#0 .../system/modules/survey_ce/ContentSurvey.php(150): Database_Statement->execute(1261816786, '1', '2', NULL, 'a:2:{s:5:"value...')
#1 .../system/modules/survey_ce/ContentSurvey.php(421): ContentSurvey->createSurveyPage(Array)
#2 .../system/modules/frontend/ContentElement.php(125): ContentSurvey->compile()
#3 .../system/modules/survey_ce/ContentSurvey.php(45): ContentElement->generate()
#4 .../system/libraries/Controller.php(363): ContentSurvey->generate()
#5 .../system/modules/frontend/ModuleArticle.php(169): Controller->getContentElement('5')
...

wenn man sich die entsprechenden Code-Zeilen ansieht ...

138    case 'anon':
139    case 'anoncode':
140        $objResult = $this->Database->prepare("DELETE FROM tl_survey_result WHERE pid=? AND qid=? AND pin=?")
141            ->execute($this->objSurvey->id, $question->id, $_SESSION["survey"][$this->objSurvey->id]);
142        $value = $question->value;
143        if (is_array($question->value))
144        {
145            $value = serialize($question->value);
146        }
147        if (strlen($value))
148        {
149            $objResult = $this->Database->prepare("INSERT INTO tl_survey_result (tstamp, pid, qid, pin, result) VALUES (?, ?, ?, ?, ?)")
150                ->execute(time(), $this->objSurvey->id, $question->id, $_SESSION["survey"][$this->objSurvey->id], $value);
151        }
152        break; 

dann erkennt man, dass dort für 'pin' ein Session-Wert ungeprüft verwendet wird. Offenbar war meine Session weg, warum auch immer. Ein normales Timeout kann es definitiv nicht gewesen sein, weil ich aktiv getestet habe und etwa jede Minute auf Weiter/Zurück geklickt habe. Eventuell hatte sich mein DSL Modem neu verbunden und ich hatte eine andere IP (führt das dann eventuell zu Sessionverlust?) oder es war etwas mit dem Server.

Wie auch immer, ich denke, man sollte Session-Werte prüfen (isset oder strlen oder isarray oder so), bevor man sie verwendet, gerade auch in SQL Statements. Mehr Sorge als das fehlgeschlagene INSERT macht mir nebenbei das DELETE in Zeile 140/141 das den selben Session-Wert verwendet, dort wurde kein Fehler gemeldet, also war es offenbar erfolgreich mit WHERE ... AND pin=NULL.

Im günstigsten Fall hat die DB das als '... AND pin IS NULL' interpretiert und damit garnichts gelöscht. Ich glaube, bei mir mit MySQL war das so. Aber wer weiss, wie andere DB's sich verhalten, schlimmster Fall wäre, dass die Bedingung schlicht ignoriert wird und dann die Antworten ALLER Teilnehmer zu dieser Frage gelöscht würden.

Wie man den Verlust der Session-Daten vernünftig handhabt, ist mir jedoch nicht klar, reicht es eventuell, das wie einen Validations-Fehler zu handhaben? Dann müsste der Teilnehmer eventuell nur die aktuelle Seite neu ausfüllen und könnte weiter machen. Sonst müsste man den Teilnehmer rauswerfen wie bei 'Umfrage abbrechen', aber bessr mit Hinweis, dass er wieder einsteigen und weiter machen kann. Helmut, alle, was denkt Ihr?

LG, Georg

[deerwood]

Hallo alle,

ein weiterer kleiner Fehler im Summary-Excel-Export:

wurde eine optionale Matrixfrage von keinem Teilnehmer beantwortet, dann fehlen zwei Zeilen im Export. Der folgende Patch korrigiert das. Dieser patch enthält ausserdem ein Beispiel für das strip_tags(), das ich eingebaut habe.

--- SurveyQuestionMatrix.php.ORG2    2009-12-22 03:01:10.473625000 +0100
+++ SurveyQuestionMatrix.php    2009-12-24 20:02:03.731875000 +0100
@@ -111,7 +111,7 @@
         array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1, "data" => utf8_decode($this->title)));
         $row++;
         array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 0, "data" => utf8_decode($GLOBALS['TL_LANG']['tl_survey_question']['question'][0]), "bgcolor" => $this->titlebgcolor, "color" => $this->titlecolor, "fontweight" => XLSFONT_BOLD));
-        array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1, "data" => utf8_decode($this->question)));
+        array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1, "data" => utf8_decode(strip_tags($this->question))));
         $row++;
         array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 0, "data" => utf8_decode($GLOBALS['TL_LANG']['tl_survey_question']['answered']), "bgcolor" => $this->titlebgcolor, "color" => $this->titlecolor, "fontweight" => XLSFONT_BOLD));
         array_push($result, array("sheetname" => $sheet,"row" => $row, "col" => 1, "data" => $this->statistics["answered"], "type" => CELL_FLOAT));
@@ -144,8 +144,9 @@
                 $counter++;
             }
 
-            $row += count($arrRows) + 2;
+            $row += count($arrRows);
         }
+        $row += 2;
         return $result;
     }
 } 

LG, Georg

[deerwood]

Hallo Helmut, alle,

weil ich die Prüfung der Ober- bzw. Untergrenzen jedenfalls bei numerischen offenen Fragen in meiner Umfrage benötige und diese Prüfung in 1.0.2 noch nicht implementiert war, habe ich sie nachgerüstet.



Siehe anliegenden Patch (zu umfangreich, um das diff -u hier zu zeigen).

Dieser Patch sorgt zusätzlich dafür, dass Werte, die die Prüfung nicht überstehen, trotzdem im Formular wieder angezeigt werden. Weil es sehr frustrierend für den Teilnehmer sein kann, wenn längliche Eingaben komplett weggeworfen werden, nur weil sie einen kleinen Fehler haben, der leicht zu korrigieren wäre.

Bei Datum und Zeit wird auch die Eingabe des Benutzers modifiziert: so ist etwa der '31.11.2009' eigentlich nicht korrekt, aber die Date Klasse akzeptiert das und interpretiert das als '01.12.2009'. Mein Patch berücksichtigt das, sowohl in einer eventuellen Fehlermeldung, wie auch im Feld-Wert. Dito für Time Felder.

Lieber Helmut, danke für Deine Erweiterung, ich denke, ich kann nun noch rechtzeitig online gehen. Ich würde mich sehr freuen, wenn meine Korrekturen/Erweiterungen von Dir (zumindest in ihrer Intention) von Dir akzeptiert würden und in die nächste Version einfließen.

Bei Interesse/Bedarf stelle ich gern ein komplettes DIFF bzw. auch meine Version von survey_ce als Download zur Verfügung.

LG, Georg

[Acta]

Hi Helmut... ich fänds nur Praktisch da ich dein Umfrage werkzeug doch ansprechnder Finde.... Das einzige was Leider nicht dabei ist, ist wie gesagt die Auswertung fürs Frontend...

Falls du mal lust und laune hast... *fg*

[hschottm]

Hallo Georg,

vielen Dank für deine zahlreichen Bugfixes und Änderungen. Ich habe alle deine Patches in die aktuelle Bugfix-Version von survey_ce ins Repository übernommen, inklusive deiner Überprüfungen der Grenzen.

Ich habe außerdem die Session-Geschichte ganz rausgenommen und bin auf eine konventionelle Weitergabe per POST-Parameter umgestiegen, es sollte also keine Probleme mehr geben mit dem Verlust der Session durch welche auch immer gearteten Umstände. Falls die PIN im schlimmsten Fall wirklich mal verloren gehen sollte, wird die Umfrage im Moment beendet und beginnt wieder von vorne. Da kann man sich unter Umständen noch mal ein Handling einfallen lassen, aber es sollte wie gesagt eigentlich gar nicht mehr vorkommen.

Jetzt will ich aber mal schnell ins Bett, denn in ein paar Stunden geht mein Flieger in die USA. Bis zum 8. Januar werde ich wohl eher nichts mehr von mir hören lassen.

Gruß,
Helmut

[deerwood]

Hallo Helmut,

herzlichen Dank für dies Weihnachtsgeschenk! Besonders, dass Du auch noch mein Problem mit der Session gelöst hast, das sind ja schon recht umfangreiche Änderungen ... und das bis spät in die Nacht und so kurz vor Deiner Abreise. Toll!

Komme gut an und guten Rutsch ins neue Jahr.
LG, Georg

[hschottm]

Hallo Helmut,

herzlichen Dank für dies Weihnachtsgeschenk! Besonders, dass Du auch noch mein Problem mit der Session gelöst hast, das sind ja schon recht umfangreiche Änderungen ... und das bis spät in die Nacht und so kurz vor Deiner Abreise. Toll!

Komme gut an und guten Rutsch ins neue Jahr.
LG, Georg

Hallo Georg,

kein Problem. Das ging ja noch, ich konnte eh nicht schlafen.
LG aus New York,
Helmut

[deerwood]

Hallo Helmut,

viel Spaß im Osten der USA!

Ich bin (und mein Kunde ist) sehr zufrieden mit der aktuellen Version, sie wird so online gehen.

Dennoch 3 weitere Ideen/Vorschläge (meine Umfrage hat ca. 15 Seiten mit etwa 120 Fragen, viele davon Matrix-Fragen):

1. Der Kunde hätte gern eine Nummerierung der Seiten/Fragen im Frontend der Umfrage. Das habe ich im Wesentlichen hinbekommen durch kleine Template-Anpassungen (die ich später gern zur Verfügung stelle): die Seiten-Titel haben jetzt einen <span> wie z.B. " (11/15)"; die Fragen haben eine Nummerierung pro Seite, immer 1 bis X. Was ich aber nicht hinbekommen konnte ist eine fortlaufendene Nummerierung der Fragen, unabhängig von der der Seite (also etwa 1-120) und auch nicht die Variante "Seiten#.Fragen#" (etwa 11.3: Wie finden Sie ...). Da müsste ich schon wieder am Code pfuschen .
2. Das "Zurück" ist in meiner Umfrage wirklich essentiell/wichtig. Und es funktioniert auch ... allerdings nur, wenn die aktuelle Seite auch valide ist. Das ist im Grundsatz natürlich OK, eine billige Alternative wäre, bei "Zurück" die aktuelle Seite garnicht zu validieren und alle Eingaben wegzuwerfen (wie in EFG). Aber das Optimum wäre, wenn (ohne jede Fehlermeldung) bei "Zurück" alle Eingaben des Teilnehmers gemerkt würden, die validen in der DB, die invaliden in der Session. Der Grund/Usecase: Teilnehmer werden oft erst aufmerksam auf ihre Eingaben in früheren Seiten, wenn sie ähnliche Fragen auf Folgeseiten beantworten sollen. Dann wollen sie "mal eben schnell zurück", um ihre Antwort dort anzupassen. So wie es ist, geht das nicht, Teilnehmer müssen erst alle Antworten der aktuellen Seite korrekt ausfüllen, bevor sie zurückgehen können ... darüber vergessen sie die notwendige Korrektur oder, noch schlimmer, sind gernervt und gehen deshalb nicht zurück.
3. ich verstehe voll und ganz, dass Du gleiche Bedingungen für alle Teilnehmer einer Umfrage erzwingst. Aber in der Test-Phase einer Umfrage ist dies Verhalten wirklich kontra-produktiv / hinderlich. Mein Vorschlag ist eine spezielle Frage in der Umfrage, die eindeutig nicht für normale Ausfüller vorgesehen ist und das auch im Fragentext entsprechend anzeigt. So wäre einigermassen gesichert, dass die Änderung der Umfrage nur stattfindet, solange entwickelt/getest wird.

Ich bin gern bereit, an der Umsetzung dieser Ideen mitzuarbeiten. Wenn Du wieder da bist, mache doch mal Vorschläge (diffs, SVN, git).

Jedenfalls nochmals vielen Dank und einen guten Rutsch ins neue Jahr

Lg, Georg

[deerwood]

Hallo Helmut, alle,

wie erwähnt, möchte ich/mein Kunde gern eine Nummerierung von Umfrage-Seiten und -Fragen. Das dient vor allem der Kommunikation sowohl im Test der Umfrage (da sind mehrere Personen beteiligt) wie auch später in der Auswertung. Die (fürs Frontend angelegte, aber noch nicht implemetierte) Durchnummerierung aller Fragen als Ganzzahl von z.B. 1-120 habe ich für meine Zwecke erstmal verworfen, weil durch Änderungen in der Test-Phase sich diese Zahlen erheblich ändern können. Stattdessen ziehe ich Seiten#.Fragen# vor, wie hier gezeigt (weil sich dann bei Ein/Verschieben/Löschen einer Frage in einer Seite die Nummerierung der Folgeseiten nicht ändert):



Fast alles davon läßt sich über normale Template-Anpassung hinbekommen (siehe das diff zwischen Original und meiner Version), nur die Seiten-Nummer in der Fragen-Nummerierung erforderte einen Patch ... ich habe echt lange Vieles ausprobiert (z.B. Umwege über $GLOBALS oder $_SESSION in Templates), konnte aber ohne Patch keine korrekten Ergebnisse erzielen. Mag sein, dass ich da etwas übersehen habe. Aber der Code-Patch ist insofern billg, als er keine zusätzlichen DB Abfragen erfordert, sondern schlicht die Seiten-Nummer an die Widgets/Fragen durchreicht.

Ich würde mich also erneut freuen, wenn Du, Helmut, diesen Code-Patch akzeptierst.

Passend dazu wäre es auch schön, im Summary-Excel diese Nummerierung (begleitend zur Fragen-Id) wiederzufinden ... dazu bin ich leider noch nicht gekommen, werde ich später mal nachliefern.

LG und frohes neues Jahr, Georg

[hschottm]

Hi Georg,

Was ich aber nicht hinbekommen konnte ist eine fortlaufendene Nummerierung der Fragen, unabhängig von der der Seite (also etwa 1-120) und auch nicht die Variante "Seiten#.Fragen#" (etwa 11.3: Wie finden Sie ...). Da müsste ich schon wieder am Code pfuschen .

Also für die Durchnummerierung habe ich in der Klasse SurveyResultDetails eine Funktion getQuestionPosition, die liefert die absolute Position einer Frage innerhalb einer Umfrage.

Die Nummerierung der Fragen mit seite#.frage# kannst du durch abändern des Templates survey_questionblock folgendermaßen erreichen: Einfach im Template hinter

<div class="title">

das folgende einfügen:

<?php echo $this->Input->post('page') + 1; ?>.<?php echo $objWidget->pageQuestionNumber; ?>.

Gruß,
Helmut

[hschottm]

So Georg,

ich hab grad noch mal nachgebessert. In der neuen Repository-Version gibt es jetzt im Template survey_questionblock drei Variablen für die Nummerierung:

• $objWidget->absoluteNumber: Die absolute Fragennummer
• $objWidget->pageNumber: Die Nummer der Seite
• $objWidget->pageQuestionNumber: Die Nummer der Frage auf der Seite

Gruß,
Helmut

[hschottm]

Das "Zurück" ist in meiner Umfrage wirklich essentiell/wichtig. Und es funktioniert auch ... allerdings nur, wenn die aktuelle Seite auch valide ist. Das ist im Grundsatz natürlich OK, eine billige Alternative wäre, bei "Zurück" die aktuelle Seite garnicht zu validieren und alle Eingaben wegzuwerfen (wie in EFG). Aber das Optimum wäre, wenn (ohne jede Fehlermeldung) bei "Zurück" alle Eingaben des Teilnehmers gemerkt würden, die validen in der DB, die invaliden in der Session. Der Grund/Usecase: Teilnehmer werden oft erst aufmerksam auf ihre Eingaben in früheren Seiten, wenn sie ähnliche Fragen auf Folgeseiten beantworten sollen. Dann wollen sie "mal eben schnell zurück", um ihre Antwort dort anzupassen. So wie es ist, geht das nicht, Teilnehmer müssen erst alle Antworten der aktuellen Seite korrekt ausfüllen, bevor sie zurückgehen können ... darüber vergessen sie die notwendige Korrektur oder, noch schlimmer, sind gernervt und gehen deshalb nicht zurück.

Das habe ich in der aktuellen Respository-Version von survey_ce ebenfalls geändert. Wenn Zurück aktiviert ist, wird keine Überprüfung mehr vorgenommen und eingetragene Werte werden übernommen. So sollte es auch sein. Evtl. füge ich später noch mal einen zusätzlichen Schalter hinzu, über den man eine Überprüfung bei zurück erzwingen kann, aber eigentlich macht das, wie du beschrieben hast, ja keinen Sinn.

Gruß,
Helmut

[deerwood]

Hallo Helmut,

vielen, vielen Dank für Deine Änderungen ... und das, obwohl Du im Urlaub bist. Eine solch prompte Reaktion, Freundlichkeit und Hilfsbereitschaft ist wirklich außergewöhnlich und bemerkenswert! Ich bin fasziniert.

Die neue Version funktioniert prächtig und vom neuen "Zurück" bin ich wirklich begeistert, Du hast das Optimum umgesetzt:

• zurück ist jederzeit sofort möglich, egal, wieviel man auf der aktuellen Seite ausgefüllt hat und wie korrekt
• wenn man nach Korrektur/Besichtigung der vorherigen Seite wieder auf der aktuellen Seite anlangt, sind sämtliche Eingaben wieder da, um sie zu vervollständigen

Das ist aus Sicht der Teilnehmer wirkliche eine riesige Erleichterung und meines Erachtens würde dies Verhalten z.B. auch dem EFG gut zu Gesicht stehen.

Danke nochmals und liebe Grüße, Georg

[truni]

Ein Kunde hat die Extension im Einsatz und bereits zweimal Fragen erstellt und modifiziert. Schon zum zweiten Mal ist er nun plötzlich ausgesperrt und alle Seiten mit Fragen sind ausgegraut und nicht mehr editierbar!

Auch als Admin kommen wir nicht mehr rein und können die Fragen nicht mehr aktivieren … was müssen wir tun? Was ist das für ein Fehler?
Bild 1.png

[Acta]

Ich würde mal Stark annehmen das der Kunde bereits die Umfrage begonnen hat. Sofern dies geschehen ist... kann er keine Fragen mehr bearbeiten.

Du oder dein Kunde können ja mal die abgegeben Stimmen zurücksetzen.. Danach müsste auch das bearbeiten wieder Möglich sein..

[truni]

Ich würde mal Stark annehmen das der Kunde bereits die Umfrage begonnen hat. Sofern dies geschehen ist... kann er keine Fragen mehr bearbeiten.

Du oder dein Kunde können ja mal die abgegeben Stimmen zurücksetzen.. Danach müsste auch das bearbeiten wieder Möglich sein..

Also ich kann «Teilnehmer der Umfrage bearbeiten» wählen. Dort scheint aber alles leer zu sein. Auch das «Alle Teilnehmerdaten löschen» führt nicht zum editierend er Fragen …

Gleichzeitig beobachtete ich aber auch Cache-Zugriffsprobleme in dieser Installation von TYPOlight. Ein Folder survey in tl_files hatte Anzeigeprobleme z.B. – mittlerweile sind diese behoben und TYPOlight wurde aktualisiert, Caches geleert usw. Einen neue Testumfrage wurde erstellt, dass der Kunde diese ausprobieren kann.

Können wir die alte nicht «wiederbeleben» resp. editierbar machen trotz allfälliger Rechte-Troubles mit Dateirechten evtl.?

[deerwood]

Hallo truni,

Also ich kann «Teilnehmer der Umfrage bearbeiten» wählen. Dort scheint aber alles leer zu sein. Auch das «Alle Teilnehmerdaten löschen» führt nicht zum editierend er Fragen …

Bei meinen Tests hatte ich auch einmal eine solche Situation: im Backend wurde angezeigt, dass es angeblich keine Teilnehmerdaten mehr gäbe. Dennoch waren in der Datenbank noch einige Antworten zu der Umfrage vorhanden. Du kannst dann so vorgehen:

Finde im Backend die Id der Umfrage heraus, die Du wieder bearbeiten möchtest. Dann lösche die Antworten zu dieser Umfrage mittels PHPMyAdmin/SQL, angenommen Deine Id ist 5, dann:

DELETE
FROM    tl_survey_result
WHERE   pid = 5

Edit: ich vergass, auch die Teilnehmer selbst und ihre Pins/Tans müssen natürlich aufgeräumt werden:

DELETE
FROM    tl_survey_participant
WHERE   pid = 5

DELETE
FROM    tl_survey_pin_tan
WHERE   pid = 5

danach sollte die Umfrage wieder editierbar sein.

Edit 2, ich habe mal versucht herauszufinden, wie es zu dieser merkwürdigen Situation überhaupt kommen kann:

wenn jemand noch im Frontend die Umfrage testet und gleichzeitig jemand im Backend "alle Teilnehemerdaten löschen" ausführt, dann werden via TYPOlight die 3 oben genannten Tabellen aufgeräumt (keine Teilnehmer, TANs/PINs und Antworten mehr für diese Umfrage). Geht jetzt der Tester aber "Weiter", dann werden seine Antworten in die DB übernommen, obwohl es den Teilnehmer garnicht mehr gibt. Es existieren dann nur noch Antworten zu der Umfrage, aber keine Teilnehmer. Deshalb können auch keine Teilnehmer gelistet bzw. gelöscht werden. Die Prüfung auf Editierbarkeit sieht jedoch auf die Existenz von Antworten zur Umfrage .. und da existieren ja einige tote Einträge. Ich denke, Helmut wird eine Lösung dafür finden, wenn er aus dem Urlaub zurück ist und Zeit hat.

Edit 3 @Helmut: so ganz geschnallt habe ich die Interaktion zwischen TL und survey_ce noch nicht . Kann man evtl. noch eine weitere Methode konfigurieren/aufrufen, die jedenfalls dafür sorgt, dass alle Teilnehmerdaten, inclusive "dangeling answers" auch gelöscht werden?

LG, Georg

[truni]

Dankeschön für die Tipps – das Leeren der Result-Tabelle genügte vollends.

Ja hier ist wohl ein Update nötig der Extension, dass egal wie die Resultate hier hinein kommen, alles sauber gelöscht wird über das Backend von TL …

Hallo truni,



Bei meinen Tests hatte ich auch einmal eine solche Situation: im Backend wurde angezeigt, dass es angeblich keine Teilnehmerdaten mehr gäbe. Dennoch waren in der Datenbank noch einige Antworten zu der Umfrage vorhanden. Du kannst dann so vorgehen:

Finde im Backend die Id der Umfrage heraus, die Du wieder bearbeiten möchtest. Dann lösche die Antworten zu dieser Umfrage mittels PHPMyAdmin/SQL, angenommen Deine Id ist 5, dann:

DELETE
FROM    tl_survey_result
WHERE   pid = 5

Edit: ich vergass, auch die Teilnehmer selbst und ihre Pins/Tans müssen natürlich aufgeräumt werden:

DELETE
FROM    tl_survey_participant
WHERE   pid = 5

DELETE
FROM    tl_survey_pin_tan
WHERE   pid = 5

danach sollte die Umfrage wieder editierbar sein.

Edit 2, ich habe mal versucht herauszufinden, wie es zu dieser merkwürdigen Situation überhaupt kommen kann:

wenn jemand noch im Frontend die Umfrage testet und gleichzeitig jemand im Backend "alle Teilnehemerdaten löschen" ausführt, dann werden via TYPOlight die 3 oben genannten Tabellen aufgeräumt (keine Teilnehmer, TANs/PINs und Antworten mehr für diese Umfrage). Geht jetzt der Tester aber "Weiter", dann werden seine Antworten in die DB übernommen, obwohl es den Teilnehmer garnicht mehr gibt. Es existieren dann nur noch Antworten zu der Umfrage, aber keine Teilnehmer. Deshalb können auch keine Teilnehmer gelistet bzw. gelöscht werden. Die Prüfung auf Editierbarkeit sieht jedoch auf die Existenz von Antworten zur Umfrage .. und da existieren ja einige tote Einträge. Ich denke, Helmut wird eine Lösung dafür finden, wenn er aus dem Urlaub zurück ist und Zeit hat.

Edit 3 @Helmut: so ganz geschnallt habe ich die Interaktion zwischen TL und survey_ce noch nicht . Kann man evtl. noch eine weitere Methode konfigurieren/aufrufen, die jedenfalls dafür sorgt, dass alle Teilnehmerdaten, inclusive "dangeling answers" auch gelöscht werden?

LG, Georg

[deerwood]

Moin Helmut, alle,

Zunächst ein Tipp: während Erstellung und Test einer Umfrage mit mehreren Seiten (vor allem, wenn Pflichtfelder vorhanden sind) kann man den Testern das Leben deutlich erleichtern, wenn die jeweils neue Seite temporär an den Anfang der Umfrage gestellt wird. Das geht ja ganz einfach via "Drag and Drop" in der Listenansicht der Umfrage und die Seiten können vor der Veröffentlichung der Umfrage genau so leicht wieder in die/eine gewünschte Reihenfolge gebracht werden.

Die folgenden Änderungen/Patches sind alle als Vorschläge/Anregungen zu verstehen und auch noch nicht wirklich ausgereift, dennoch haben sie mir geholfen und ich glaube, dass sie auch anderen helfen können.

In der Listenansicht der Umfrage fehlten mir die "Bemerkungen" zu den Seiten, die ich mühsam eingegeben hatte. Siehe diff dazu.

In der Listenansicht einer Umfrage-Seite fehlte mir die Kennzeichnung, ob es sich um ein Pflichtfeld handelt und gelegentlich wollte ich auch den Hilfetext sehen können. Siehe dieses diff. Damit werden Pflichtfelder mit * markiert und der Hilfetext als "title" Element ausgegeben.

Dank Helmuts toller Erweiterung ist meine Umfrage (14 Seiten, ca. 120 Fragen, viele davon Matrix-Fragen, nur angemeldete Frontend-Mitglieder, aber über einen gemeinsamen Zugang, ansonsten anonym) nun online. Und die ersten echten Daten trudeln ein.

Bei der Kontrolle der echten Teilnehmerdaten wurde mir klar, dass diese Sicht auf die Daten bisher ein wenig schwächelt . Einzig wirkliche Info war begonnen/abgeschlossen ...aber ich bin an mehr interessiert und die Teilnehmerdaten geben auch mehr her. Außerdem muss ich in meiner Umfrage mit etwa 600 Teilnehmern rechnen, die die Umfrage zumindest beginnen und damit als Teilnehmer gelistet werden.

Mit dem letzten diff/Patch erhalte ich jetzt im Backend eine Ausgabe, wie im anhängenden Bild gezeigt.

Sortierung im Moment möglich nach der letzten ausgefüllten Seite und nach Änderungsdatum, Filterung nach der letzten ausgefüllten Seite, und man muss nicht alle (irgendwann einmal) 600 Teilnehmer auf einmal ansehen und endlos rollen.

Damit kann ich z.B besser beurteilen, ob der (anonyme) Teilnehmer testet / kurz reingeschaut hat, oder ernsthaft teilgenommen hat (die ganz schwierigen Fragen sind am Ende / in den letzten Seiten der Umfrage, es ist damit zu rechnen, dass nicht alle Teilnehmer bis zur letzten Seite vordringen und absenden, dennoch sind ihre Eingaben auf den vorherigen Seiten sinnvoll auswertbar).

Wie gesagt, alles nur Vorschläge, mir half das, für mich funktioniert es auch, aber ich übernehme keine Garantie, dass das auch für Euch funktioniert.

HTH, LG, Georg

[hschottm]

Dankeschön für die Tipps – das Leeren der Result-Tabelle genügte vollends.

Ja hier ist wohl ein Update nötig der Extension, dass egal wie die Resultate hier hinein kommen, alles sauber gelöscht wird über das Backend von TL …

Genau und das ist jetzt auch im Repository verfügbar. Es wird nun überprüft, ob überhaupt noch eine gültige PIN eines Teilnehmers für eine Umfrage vorhanden ist. Wenn nicht (weil diese z.B. gerade vom Administrator durch entfernen der Ergebnisse gelöscht wurde), kann der Teilnehmer die Umfrage nicht weiter durchführen und wird bei einem Schreibversuch (weiter/zurück) aus der Umfrage "rausgeschmissen".

[deerwood]

Moin Helmut,

nach Abschluss meiner Umfrage-Seiten/Fragen (in deutsch) und erfolgreichem Test durch alle Beteiligten habe ich alle Teilnehmerdaten gelöscht (definitiv, mit Kontrolle via SQL) und dann die ganze Umfrage dupliziert und unter anderem Namen gespeichert, um diese dann später nach EN übersetzen zu können.

Das sah, bei einem kurzen Check, auch gut aus ... alle Seiten da und bei einigen Stichproben auch alle Fragen auf diesen Seiten. Dann habe ich die deutsche Version aktiviert und die Ergebnisse trudeln ein, so dass ich am Original nichts mehr ändern kann.

Heute, beim Versuch die Kopie nach EN zu übersetzen, fiel mir auf, dass bei einer Seite sämtliche Fragen fehlten. Komisch, aber da mag ich vielleicht etwas falsch gemacht haben; das ist noch nicht das echte Problem ... obwohl es schon frustierend ist, dass man die fehlenden Fragen in EN nicht einfach aus DE per Copy/Paste holen kann, weil ja sämtliche Seiten in DE komplett gesperrt sind und man so die Fragen nicht einmal sehen, geschweige denn kopieren kann.

Gerade eben habe ich dann (gedacht/getan) die laufende DE Umfrage nochmals dupliziert und sie unter einem dritten Namen/ID gespeichert.

Und nun das Problem:

Die 3. Umfrage ist da, aber deren Seiten nicht bearbeitbar ... hmm. Inspektion der DB: alle Teilnehmer, PINs/TANs und Antworten wurden offenbar dupliziert ... das ist zwar konsequent, aber nicht erwünscht/unerwartet, oder?

Höchst merkwürdig ist dann noch, dass die kumulierte Übersicht, wie auch der Excel-Export diese offensichtlich vorhandenen Daten völlig ignoriert. Das zumindest ist ein echter BUG/Fehler!

Da meine Daten eintrudeln und bei Existenz eines BUGs traue ich mich im Moment nicht, die 3. Umfrage komplett wieder zu löschen, weil ich das Problem noch nicht identifizieren konnte und befürchte, dass ich echte (wirklich wichtige) Daten weglösche!

Hast Du einen Tipp/Idee?

Beachte auch, dass ich mit meinen letzten Patches arbeite und noch ohne Deinen neuesten Build 20 (19 + my patches, obwohl ich nicht glaube, dass diese das Problem verursacht haben, oder?)

Notfalls helfe ich mir via SQL, aber es wäre schon schön, wenn survey_ce das gleich richtig hinbekommt.

LG, Georg

PS: bist Du nun eigentlich schon wieder da und hast Zeit?

[deerwood]

Moin,

nun habe ich mir via SQL geholfen, wie oben schon einmal gezeigt.

Die 3. Version der Umfrage ist nun editierbar.

Allerdings fehlen nun die Fragen zu einer völlig anderen Seite als in Version 2 der Umfrage! Alle anderen Fragen scheinen da zu sein, die laufende Original-Umfrage in DE scheint unbetroffen zu sein, dort sind alle Seiten/Fragen nach wie vor da.

Für das Fehlen von Fragen auf mal der einen und mal der anderen Seite in den Duplikaten habe ich noch so gar keine Idee.

Das Duplizieren von auch Teilnehmern, TAN/PIN und Antworten erklärt sich wohl aus dem TL Framework, das bei entsprechender Metadaten-Definition via DCA 'ptable' und 'ctable' auswertet und dann, wenn die Columns 'pid' und 'id' in den Tabellen vorhanden sind, seinen Standard-Job macht. Aber da gibt es, glaube ich, Einstellungen wie "do not copy" oder so .. sorry, ich bin echt noch nicht tief genug in TL.

Vielleicht springt hier ja mal ein anderer Fachmann ein und hilft, bis Helmut wieder da ist?

Danke, LG, Georg

[deerwood]

Moin Helmut,

Es wird nun überprüft, ob überhaupt noch eine gültige PIN eines Teilnehmers für eine Umfrage vorhanden ist. Wenn nicht ... kann der Teilnehmer die Umfrage nicht weiter durchführen und wird bei einem Schreibversuch (weiter/zurück) aus der Umfrage "rausgeschmissen".

Jupp, viel besser als meine unausgegorene Idee!

Noch nicht getestet, aber der Teilnehmer kann dann ohne weiteres neu anfangen, wird dann erneut korrekt als Teilnehmer mit PIN/(TAN) in die DB übernommen und kann weiter machen (neu anfangen) ... mein Designer-Kollege (der das CSS macht) wird fluchen, aber es ist das korrekte Verhalten! Und er kann ja meist mit "reload" gut leben .

LG, Georg

PS: 116 Teilnehmer in meiner Umfrage nach 2 Tagen, davon ca. 60, die abgeschlossen haben, ca. 20, die nur Seite 1 angesehen haben (Lösch-Kandidaten). Zeigt, dass ich in der Liste der Teilnehmer wirklich mehr brauche, als begonnen/beendet.

[hschottm]

Moin Georg,

ich bin wieder da, kämpfe aber noch mit meinem Jet Lag...
Zeit ... nun ja, die habe ich eigentlich nicht, aber in dem Fall werde ich sie mir definitiv nehmen (müssen). Die ganze Sache mit dem Kopieren erledigt das TL-Framework, weshalb auch die Tabellen mit den Teilnehmern mitkopiert werden. Schön ist das nicht, da gebe ich dir vollkommen recht, aber wenn es wirklich Einstellungen gibt, die verhindern, dass bestimmte Tabellen mitkopiert werden (da gehe ich jetzt sogar von aus, nachdem du das gesagt hast), dann werde ich das auf jeden Fall so ändern, dass die Teilnehmerdaten natürlich nicht mitkopiert werden.
Dass nun bestimmte Seiten gar nicht kopiert werden, da kann ich mir im Augenblick überhaupt keinen Reim drauf machen. Es kann ja nur zwei Möglichkeiten geben: Entweder stimmen die Framework-Methoden nicht ganz Hundertprozentig, was ich mal nicht glauben will oder ich habe irgendwo Bockmist gebaut (was wesentlich wahrscheinlicher ist). Ich werde mal ein paar Umfragen duplizieren und hoffen, dass der Fehler bei mir auftritt und ich das Problem reproduzieren kann.

Gruß,
Helmut

[hschottm]

So, die Geschichte mit dem Kopieren der Datensätze (PIN/TAN, Ergebnisse und Teilnehmer) ist im Repository behoben. Ein einfaches Einfügen von

        'doNotCopyRecords'            => true, 

im config-Array der DCA-Beschreibungen von tl_survey_pin_tan, tl_survey_participant und ein Hinzufügen des Config-Arrays für tl_survey_result verhindern das Kopieren der Daten, die beim Kopieren nicht dupliziert werden sollen.

Um das Problem der verschwundenen Fragen kümmere ich mich dann jetzt.

Gruß,
Helmut

[hschottm]

Lieber Georg,

ich habe deine letzten Patches für die Anpassung der Ausgaben (Pflichteingaben bei Fragen in der Übersicht, Bemerkungen in der Listenansicht, Erweiterte Ergebnisausgabe (Sortieren nach Datum, letzte bearbeitete Seite)) übernommen, da ich sie alle sehr gut finde. Wir müssen langsam mal drüber reden, dass du auf jeden Fall in den Copyrights zu der Erweiterung mit auftauchst

Ich habe mir erlaubt, kleinere Änderungen vorzunehmen (Pflicht-Sternchen ist jetzt rot und bei den Seiten habe ich die eckigen mit den runden Klammern vertauscht und eine andere Farbe gewählt).

Aber im Prinzip könntest du dann jetzt auf die aktuelle Respository-Version aktualisieren. Es sei denn, du hast schon wieder neue Patches gemacht

Ich kann das Problem mit den ausgelassenen Fragen beim duplizieren leider nicht reproduzieren. Ich habe eine etwas komplexere Umfrage mit 5 Seiten und 40 Fragen, die wird immer korrekt kopiert. Ich kann mich dunkel erinnern, dass ich während der Entwicklungsphase auch mal ein solches Problem hatte, weiß aber leider auch nicht mehr die Lösung.

Gruß,
Helmut

[deerwood]

Lieber Helmut,

schönen Dank für Deinen Einsatz, ich werde heute Nacht mal die neue Version installieren.

Zu den ausgelassenen Fragen habe ich auch keine Idee, weil da ja auch gar kein Code zum Duplizieren in survey_ce steht, sondern nur DCA Konfiguration, oder? Ich habe aber einen Workaround: ich hatte ja nun 2 Duplikate mit fehlenden Fragen, aber je auf unterschiedlichen Seiten ... also habe ich mir die Seite mit fehlenden Fragen im einen Duplikat aus dem anderen Dup per Copy/Paste geholt und habe so ein vollständiges Dup, das jetzt übersetzt wird.

Noch eine Frage zum Sprachenfeld in Umfrage und Frage: hat das irgendwelche Auswirkung, ausser bei der Skalenauswahl? Falls nicht, hast Du damit Pläne?

Eine Sache, die mir noch auffällt (habe den Code aber noch nicht angesehen): Aufruf von "Statistik der Umfrage ID X anzeigen" ist SEHR langsam, dauert etwa so lange, wie der kumulierte Excel Export, selbst bei einer Umfrage ohne Teilnehmer/Antworten. Das fällt vor allem auf, wenn man sich die Details hat anzeigen lassen und dann mit "Zurück" wieder in die Liste geht (der Hilfe-Hover für Details anzeigen lautet nebenbei "Array"). Hier wäre eine Optimierung wünschenswert.

Noch eine Kleinigkeit: zumindest in offenen Fragen werden die runden Klammern '(' und ')' als &#38;#40; und &#38;#41; in tl_survey_result geschrieben und dann auch so ins Excel geschrieben.

Ansonsten werde ich mich in den nächsten Tagen mal an den detaillierten Excel Export machen.

Nochmals vielen Dank, LG, Georg

[Acta]

Hallo georg,

beim Iphone würde ich Fragen gibts da ne App... bei dir wäre wohl Korrekt... gibt da nen Patch ^^

Also hier meine Frage... Wie wertet dein Kunde die Umfrageergebnisse aus?

Nur intern? Oder Spiegelt er die Ergebnisse auch irgendwo auf seine Homepage ab?

[deerwood]

Moin Acta,

Hallo georg,

beim Iphone würde ich Fragen gibts da ne App... bei dir wäre wohl Korrekt... gibt da nen Patch ^^

Also hier meine Frage... Wie wertet dein Kunde die Umfrageergebnisse aus?

Nur intern? Oder Spiegelt er die Ergebnisse auch irgendwo auf seine Homepage ab?

In meinem Fall sollen die Umfrage-Ergebnisse jedenfalls NICHT auf der Webseite zu sehen sein, auch nicht für die Teilnehmer der Umfrage. Der Hintergrund: obwohl die Umfrage vom Typ "Anonym" ist, müssen die Teilnehmer einige Pflichtfelder ausfüllen (etwa ihre email) und auch Daten, die andere Teilnehmer sicher nicht sehen dürfen/sollen (z.B. Anmerkungen, Umsätze). So ist das eigentlich eine personalisierte Umfrage, aber ich spare mir die Einrichtung vieler hundert potentieller Teilnehmer als Frontend-Mitglieder und die ganzen Probleme mit dem Zusenden von Zugangsdaten, vergessenen Passworten usw. Die Hürde zur Teilnahme ist so viel geringer.

Allerdings kann der Teilnehmer in der Umfrage ankreuzen, ob er eine kurze Zusammenfassung der Umfrage erhalten möchte ... da filtert mein Kunde dann natürlich manuell persönliche Daten raus und das wird wohl auch schlicht ein email-Text werden ... jedenfalls nichts, was man wirklich automatisch erzeugen könnte.

Also kurz: Nur intern!

Ich sehe aber durchaus Deinen Bedarf ein und Helmut hatte weiter oben schon signalisiert, dass er das auf seiner TODO-Liste hat. Dann sehe ich aber auch die Notwendigkeit, die eine oder andere Frage als "Nicht im öffentlichen Resultat anzeigen" zu markieren.

Nebenbei hatte ich auch mit EFG experimentiert, aber mich für survey_ce entschieden, wegen u.A.: sehr guter Dokumentation, der Möglichkeit von Matrix-Fragen (setze ich intensiv ein z.B. für Bewertungen 1-5 aka "Sehr gut" bis "Sehr schlecht") und dem kumulierten Ergebnis als Excel. Mit den kumulierten Ergebnissen ist mein Kunde erst einmal sehr zufrieden.

Aber er benötigt zusätzlich auch eine Filterung/Sortierung nach verschiedensten Kriterien, die allerdings von den Fragen selbst abhängen (z.B. regionale Infos wie Land und/oder PLZ, oder Umsatz). Und, in einem ersten Schritt, will ich mich nun an den detaillierten Export machen und auf Excel/OOO Calc Features zurückgreifen. Den Aufwand, survey_ce so zu erweitern, dass er z.B. vor Export eines kumulierten Ergebnisses noch Filter anwenden kann, die von der Umfrage selbst abhängen, kann ich zur Zeit wirklich nicht abschätzen ... das wäre, glaube ich, eher ein langfristiges Ziel, wenn man mal viel Zeit hat.

LG, viel Erfolg mit Deiner Umfrage, Georg

[deerwood]

Hallo Helmut,

Dein neuer Build 27 funktioniert wunderbar, danke für die schönere Formatierung und vor allem die Fixes, die Du eingebaut hast (duplizieren habe ich aber noch nicht getestet ... ich würde gern noch ein wenig zuwarten, bis meine Teilnehmer im Wesentlichen fertig sind, damit ich notfalls ein Backup wieder einspielen kann).

Zu 'ptable' vs. 'ctable' und 'doNotCopyRecords' => true in TYPOlight DCAs:

Mir bleibt unklar, ob man nicht besser ganz konsequent sein sollte und beides, an den richtigen Stellen, eingeben sollte?!!!

Beispiel, Du hast in Build 27 ja nun eine neue DCA für 'tl_survey_result', die das 'doNotCopyRecords' Flag enthält ... aber sonst eben nichts. In 'tl_survey' ist im 'ctable' Array auch 'tl_survey_result' genannt und damit müsste TL eigentlich schon ausreichend über den 1:N Zusammenhang informiert sein. Andererseits GIBT es den Eintrag 'ptable' eben auch, und irgenwie ist mir unwohl, wenn die Antwort-Tabelle den Parent-Table Eintrag nicht hat.

Die ganze DCA-Konfiguration ist leider wirklich nur rudimentär dokumentiert, sowohl online, wie auch im aktuellen Buch, obwohl sie eine so zentrale Rolle im Backend spielt. Oder habe ich etwas übersehen? Bisher jedenfalls musste ich mir immer wieder, durch Inspektion von vorhandenen DCAs und reverse Engineering von Code das eine oder andere zusammenreimen, ohne sicher sein zu können, dass ich es richtig verstanden habe.

Edit: sieh auch meine Frage im Entwickler-Forum.

Ach, und ich habe Dir falsche Hilfetexte geliefert für Teilnehmer "Letzte Seite/Last page": das ist eben NICHT die "Letzte Seite, die der Teilnehmer erfolgreich ausgefüllt hat", sondern die "Letzte Seite, die der Teilnehmer angesehen hat". Das ist schon ein großer Unterschied: ich habe z.B. in der Teilnehmerliste, gefiltert nach der letzten Seite, 2 Teilnehmer, die noch nicht beendet haben und deshalb als "[begonnen (14/14)]" ausgewiesen werden. Und alle Teilnehmer, die als "[begonnen (1/14)]" ausgewiesen werden, haben nicht einmal die erste Seite erfolgreich ausgefüllt, sondern offensichtlich die Umfrage nur einmal kurz angesehen und sind dann wieder verschwunden. Lösch-Kandidaten, wenn das auch nach Abschluss der Umfrage noch so ist. Sorry.

LG, Georg

[hschottm]

Ach, und ich habe Dir falsche Hilfetexte geliefert für Teilnehmer "Letzte Seite/Last page": das ist eben NICHT die "Letzte Seite, die der Teilnehmer erfolgreich ausgefüllt hat", sondern die "Letzte Seite, die der Teilnehmer angesehen hat". Das ist schon ein großer Unterschied: ich habe z.B. in der Teilnehmerliste, gefiltert nach der letzten Seite, 2 Teilnehmer, die noch nicht beendet haben und deshalb als "[begonnen (14/14)]" ausgewiesen werden. Und alle Teilnehmer, die als "[begonnen (1/14)]" ausgewiesen werden, haben nicht einmal die erste Seite erfolgreich ausgefüllt, sondern offensichtlich die Umfrage nur einmal kurz angesehen und sind dann wieder verschwunden. Lösch-Kandidaten, wenn das auch nach Abschluss der Umfrage noch so ist. Sorry.

Hallo Georg,

ohne sorry bitte Das hätte ich ja auch noch überprüfen können. Ich hab's jetzt jedenfalls geändert.

LG,
Helmut