Einträge per FE Edit löschen?

[scribble]

Hallo zusammen

Hab mir die Wiki Einträge und Tutorials angeschaut, aber irgendwie werde ich nicht schlau daraus - wie löscht ein FE User seine Katalogeinträge?

Im Tutorial markiert er Sie einfach per Checkbox, damit der Admin den Eintrag entfernt. Ist ein direktes Löschen per FE Edit nicht möglich?

Vielen Dank für Euren Support.
Sam

[MacKP]

Hallo scribble,
ein direktes löschen ist bisher nicht vorgesehen.
Ich mache das einfach mit einem extra Feld (checkbox). Die angekreuzten Items werden im Frontend nicht mehr angezeigt. Der Vorteil: versehendlich gelöschtest kann von einem Backend Admin wiederhergestellt werden.

Viele Grüße

[scribble]

Versionierung ein Thema?

Hallo MacKP

Vielen Dank für Deine Antwort.

Ist Versionierung eigentlich ein Thema für den catalog - also die Versionierung von Inhalten nicht den Feldern - da klappt das Ganze ja schon perfekt.

Cheers
Sam

[MacKP]

Hallo MacKP

Vielen Dank für Deine Antwort.

Ist Versionierung eigentlich ein Thema für den catalog - also die Versionierung von Inhalten nicht den Feldern - da klappt das Ganze ja schon perfekt.

Cheers
Sam

Hallo scribble,
da möchte ich mal mit einem Zitat vom Usertreffen von mir antworten:
Wir (der catalog) hat den Workflow im Frontend (geht mit dca auch im Backend inzwischen), und TYPOlight hat das Versionsmanagement.

Ich wüßte aktuell nicht wie die Entwickler das einbauen könnten... aber du kannst das natürlich auf die feature Liste in Google setzen ;-)

Viele Grüße

[xtra]

Die Thematik der Versionierung hatten wir in der Vergangenheit schon oefters.
Problematisch hierbei ist, dass sich die beiden Versionierungen auf jeden Fall ins Gehege kommen.

Man Nehme an, wir haben ein Feld, Typ text.
Legen einen Eintrag an.
Aendern diesen. => Versionierung wird gespeichert.
Aendern den Feldtyp auf Integer. => Versionierung vom Feld wird gespeichert.
Rycksicherung der alten Version des Eintrags => BUMM Der alte Textinhalt passt nicht mehr ins neue Feld welches ein Integer ist.

Dieses Beispiel ist stark vereinfacht, es gibt auch noch die Faelle, wo Felder entfernt werden, neue hinzukommen etc.
Fyr diese Problematik gibt es bislang keine (vertretbare) Loesung.

Gruss
Chris

[scribble]

Hallo MacKP, Hallo Chris

Vielen Dank für Eure Antworten. Ich sehe das Problem. TL arbeitet ja so, dass jedes erstellte Element alle Eventualitäten erfasst, d.h. Tabellen mit einer ziemlich anständige Anzahl Spalten entstehen.

Zusätzlich zu den für jeden Katalog vordefinierten Spalten id, pid, sorting und tstamp müssten für alle verfügbaren Feldtypen (text, integer, dezimal, etc.) Spalten angelegt werden. Bei Änderungen müssten immer mehrere Spalten (soweit möglich) befüllt werden.

Nehmen wir dein Beispiel:
1. Feld "A", Typ text.

2. Legen einen Eintrag an. Hier würde der Inhalt soweit möglich konvertiert und in allen Spalten gespeichert.

3. Aendern diesen. => Versionierung wird gespeichert.

4. Aendern den Feldtyp auf Integer. => Versionierung vom Feld wird gespeichert- bei der Änderung des Feldtyps müsste zugleich eine Kompatibilitätsprüfung der Inhalte stattfinden und der User würde entsprechend per BE UI informiert.

5. Rufen wird diesen Wert wieder ab, wird uns der Inhalt der Spalte "integer" (der Katalogtabelle) angezeigt und nicht mehr derjenige der Spalte "text".

Natürlich verursacht diese Lösung viel Rechenlast ohne offensichtlichen Nutzen.

Ein Workaround (ohne zusätzliche Spalten) wäre allenfalls ein Abgleich des geladenen Inhalts mit dem aktuellen Feldtypen bevor der Inhalt bearbeitet/angezeigt werden kann.

Ich bin mir sicher, dass ihr schon etliche Varianten durchgegangen seid, wollte das hier nur kurz posten, weil sich vielleicht andere dieselbe Frage stellen.
Eine perfekte Lösung wird es wohl nicht geben, da vor allem bei grossen Katalogen das schnell kompliziert wird - wie du schon sagst ;-)

Cheers
Sam