Ankündigung

Einklappen
Keine Ankündigung bisher.

FrontendEdit: Fehler Weiterleitung und Flag beim Kopieren löschen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • FrontendEdit: Fehler Weiterleitung und Flag beim Kopieren löschen

    Hi, habe soeben erfolgreich meinen ersten Katalog angelegt, der von eingeloggten Mitgliedern über das Frontend editierbar ist. Jedes Mitglied sieht dabei nur seine eigenen Einträge. Alle Elemente werden abschließend durch einen Admin "veröffentlicht". Soweit, so gut. Leider habe ich noch zwei Probleme, bei denen ich auf eure Hilfe hoffe: Einmal, die Weiterleitung von der Liste auf den Reader funktioniert nicht. Wenn das Mitglied auf das Symbol "+neues Element" klickt, dann wird nicht der Reader geladen, sondern es erscheint die Fehlermeldung "Ungültiges Abfrage Token, das Request Token konnte nicht validiert werden". Die Mitgliedergruppe besitzt die Berechtigung zum Editieren: Löschen und das Bleistift-Symbol funktionieren, ebenso das Kopieren von Datensätzen.

    Bezüglich Datensätze kopieren: Wurde der Original-Datensatz zuvor vom Admin schon veröffentlicht, wird dieses Flag logischerweise mitkopiert, so dass der kopierte Datensatz sofort veröffentlicht wird. Das Flag sollte allerdings beim kopieren auf "false" gesetzt werden.

    Vielen Dank für eure Hilfe!

    Bernhard

  • #2
    Bezüglich Datensätze kopieren: Wurde der Original-Datensatz zuvor vom Admin schon veröffentlicht, wird dieses Flag logischerweise mitkopiert, so dass der kopierte Datensatz sofort veröffentlicht wird. Das Flag sollte allerdings beim kopieren auf "false" gesetzt werden.
    Das entspricht auch dem Verhalten des Backends. Beim Kopieren wird der tstamp auf 0 gesetzt. Damit kann die Listen-Darstellung gefiltert werden: Eigenes SQL: tstamp > 0. Auch das Backend unterscheidet an Hand dieser Spalte, ob ein Eintrag temporär ist oder real gespeichert wurde.

    http://www.premium-contao-themes.com

    Kommentar


    • #3
      Zitat von Tim Beitrag anzeigen
      Das entspricht auch dem Verhalten des Backends. Beim Kopieren wird der tstamp auf 0 gesetzt. Damit kann die Listen-Darstellung gefiltert werden: Eigenes SQL: tstamp > 0. Auch das Backend unterscheidet an Hand dieser Spalte, ob ein Eintrag temporär ist oder real gespeichert wurde.
      Würde prinzipiell zwar gehen, allerdings sieht der Admin im Backend nicht, welcher Datensatz noch veröffentlicht werden muss, da das "Augen" Symbol in jedem Fall grün ist.

      Kommentar


      • #4
        weitaus mehr Kopfzerbrechen macht mir derzeit das Problem, dass wegen des "Ungültiges Abfrage Token" Fehlers keine neuen Datensätze angelegt werden können.

        Kommentar


        • #5
          Zitat von Bernhard87 Beitrag anzeigen

          Würde prinzipiell zwar gehen, allerdings sieht der Admin im Backend nicht, welcher Datensatz noch veröffentlicht werden muss, da das "Augen" Symbol in jedem Fall grün ist.
          Prinzipiell fängt man jetzt natürlich an grundsätzliche Arbeitsumgebungen zu mischen. Das sollte man beachten.

          Technisch:
          Durch ein eigenes verstecktes Input-Feld im Template, nach dem Veröffentlichen Feld, kann der Wert ja neuübergeben werden. Dort eine 0 als Wert.
          http://www.premium-contao-themes.com

          Kommentar


          • #6
            Klasse! Vielen Dank Tim, das funktioniert. Wenn Du auch eine Idee zu dem Token-Fehler hast, gerne ;-)

            Edit: Ich habe zwischenzeitlich herausgefunden, dass beim Anklicken des "+neues Element" Links trotz des Token Fehlers ein neuer Datensatz geschrieben wird, bei dem alle Felder bis auf eines leer sind: Lediglich der Wert des eingeloggten FE-Users aus dem "Elemente Schützen" Element wird in den Datensatz geschrieben.
            Zuletzt geändert von Bernhard87; 20.11.2018, 12:16.

            Kommentar


            • #7
              So, ich habe jetzt wie in https://community.contao.org/de/show...sand-und-LogIn beschrieben, die Request-Tokens global mittels

              $GLOBALS['TL_CONFIG']['disableRefererCheck'] = true;

              in der localconfig.php disabled und schon gings. Das Löschen aller Caches, wie anderswo empfohlen war nicht erfolgreich. Das ist für einen Server im Produktionsbetrieb später vermutlich, äh..., suboptimal. Scheint ein Bug zu sein, den Contao 4.4. schön länger mit sich herumschleppt.

              Kommentar

              Lädt...
              X