contao
Kopie eines Contao-Kalenders: Start- und Enddatum werden nicht übernommen
Wir haben einen Kalender mit ca. 100 Events gefüllt, den wir für zwei Seitenbäume benötigen, der Inhalt der beiden Kalender dann später aber nicht zu 100% übereinstimmt, denn im zweiten Kalender werden noch zusätzliche Einträge gemacht. Beim Kopieren des kompletten Kalenders oder einzelner Events des Kalenders werden Start- und Enddatum aller Events jedoch nicht mit in die Kopie übernommen, sondern das Startdatum durch das aktuelle Datum ersetzt und das Enddatum komplett gelöscht. Da in meinem Fall jedoch die meisten Daten wie im Original-Kalender erhalten bleiben sollen, muss nach dem Kopieren jedes Event noch einmal bearbeitet und korrigiert werden. Ansonsten ist die Kopieren-Funktion nutzlos und ich muss alle Einträge noch einmal händisch eingeben.
Nachvollziehbar in der Contao-Demo:
- Ganzer Kalender: Events --> Kalender: Contao Public Example Events kopieren --> Speichern --> alle Start-Datumfelder stehen auf aktuellem Datum
- Einzelne Events: Kalender: Contao Public Example Events bearbeiten --> Event kopieren --> Speichern --> Das Start-Datumsfeld steht auf aktuellem Datum
Mein System: Contao 3.4.5
Hallo, ich denke nicht, dass dies ein Bug oder ein Feature-Request ist. Das ist wohl ne Frage fürs Forum.
Siehe auch https://docs.contao.org/books/manual/3.5/de/06-data-container-arrays/referenz.html 'doNotCopy'.
Außerdem scheint mir das schlechter Style zu sein doppelte Datensätze zu verwalten. Der zweite Kalender braucht eigentlich nur die "zusätzlichen" Events. Die FE-Module können Events aus mehreren Archiven ausgeben. Oder die Events brauchen ein neues Feld (Tag) anhand dessen man die Events unterscheiden kann.
Zukünftig sollen die beiden Kalender von unterschiedlichen Personen verwaltet werden, wobei nicht beide Personen auf beide Kalender zugreifen sollen, sondern immer nur auf den Eigenen. Auch aus dem Grund, dass eben nicht alle Daten, sondern nur ca. 80% der Altdaten in beiden Kalendern übereinstimmen, macht die bisherige Datenübernahme in zwei Kalender m.E. schon Sinn. Warum also mit mehreren Kalenderarchiven pro Seitenbaum arbeiten, wenn es auch mit einem gehen kann? Der Datenbestand driftet ab jetzt sowieso auseinander...
Wie sieht es mit diesem Anwendungsfall aus: 2. Sprache per 2. Seitenbaum, Kalender duplizieren und Kopie übersetzen... Wie soll man das sonst machen? Das aktuelle Verhalten verfälscht jedenfalls die vorhandenen Events!
Generally, there is no advantage of having doNotCopy set to true for these fields. As @OppaBredow mentioned here, if you need to copy an event and change the date, it does not matter to you if the date was copied or not - since you need to change it in any case. If you need to copy an event and not change the date, then doNotCopy => true unnecessarily causes more work.
Wir haben das am 21. Juli auf Mumble diskutiert und das Problem ist, dass doNotCopy im Prinzip kontextabhängig ist. Kopiert man ein einziges Event, sollte das Startdatum leer sein. Kopiert man aber einen ganzen Kalender, macht es ggf. Sinn, die Startdaten übernehmen.
Kopiert man ein einziges Event, sollte das Startdatum leer sein.
Warum, welchen Vorteil hat man dadurch?
Ich finde das jetzt auch eher verwirrend und würde auf eine Anpassung diesbezüglich verzichten. Wen das gleiche Datum bei einer Kopie explizit in seinem Workflow stört, der kann es sich ja über seine dcaconfig überschreiben. Ich denke doNotCopy=false sollte die bevorzugte Standardeinstellung bleiben.
Zum Beispiel dass der Datepicker beim aktuelle Datum startet und nicht beim kopierten. Dass man direkt ins Feld tippen kann ohne den Wert zuerst löschen zu müssen.
Wenn ich kopiere, dann erwarte ich eine Kopie und es wäre verwunderlich, wenn dort dann ein anderes Datum wäre.
Wenn ich einen neuen Event erstelle, dann sehe ich das von Vorteil, dass das Textfeld leer ist und der Datepicker beim aktuellen Datum startet.
Also sollte doNotCopy meiner Meinung nach jetzt tatsächlich am besten in allen Fällen auf false stehen.
Meine Meinung (https://github.com/contao/core/issues/6096) hat sich nicht geändert und wurde schon mehrmals durch unsere Kunden bestätigt: Eine Kopie ist eine Kopie und entspricht erwartungsgemäss dem Original.
Das doNotCopy ist eine schönes Feature. Es soll aber nur eingesetzt werden, wenn der Fall eindeutig ist wie, z.B. alias, author oder published
Zum Beispiel dass der Datepicker beim aktuelle Datum startet und nicht beim kopierten.
Das ist aber kein definitiver Vorteil.
Dass man direkt ins Feld tippen kann ohne den Wert zuerst löschen zu müssen.
Das ist auch kein definitiver Vorteil, darüberhinaus musst du das bei einem neuen Event auch so machen.