Ich möchte eigentlich nicht wieder eine Grundsatzdiskussion lostreten, aber ein paar Anmerkungen habe ich schon noch:
Dem "Never" für das Event onChange muss ich widersprechen. Natürlich gefällt mir die Variante mit Postopen merken und Querysave schreiben selbst auch am besten, ist aber für einen Neuling schwieriger, da in drei verschiedenen Elementen etwas eingetragen werden muss. Declarations, Postopen und Querysave, evtl. auch im Queryclose. Beim onChange ist es ein einziges Script (allerdings pro Feld). Was kann passieren, wenn man onChange nimmt? Der Benutzer ändert den Inhalt des Feldes von A in B und aktualisiert/speichert das Dokument, die Historie wird eingetragen. Dann überlegt er sich das anders und ändert zurück in A. Wieder erfolgt ein Eintrag in die Historie. Was ist daran falsch? Der Benutzer hat definitiv an dem Feld herumgefummelt, auch wenn am Ende faktisch keine Änderung erfolgt ist. Wo ist der Unterschied zu einem Öffnen des Dokuments, Ändern, Speichern, Schließen, Überlegen, wieder Öffnen, Zurückändern, Speichern und Schließen? Warum soll das eine protokolliert werden und das andere nicht? Finde ich nicht wirklich gravierend falsch.
Zum Queryclose: Ein Schreiben einer Historie im Queryclose bedeutet, dass das Dokument beim Schließen, nach dem letzten Speichern, noch einmal gespeichert werden muss. Das funktioniert in schlichten Anwendungen sicher problemlos. Aber wie sieht das in Dokumenten aus, die einem Workflow unterliegen? Möglicherweise ist der Benutzer beim Schließen des Dokumentes nicht mehr Autor des Dokuments, weil er es an den nächsten Bearbeiter weitergegeben hat (da muss dann im Querysave ein temporäres Autorenfeld gesetzt werden, was im Queryclose wieder entfernt werden muss, weil sonst der Workflow dahin ist). Eventuell gibt es durch die Veränderung im Workflow nun neue Validierungsregeln, die ein Speichern im Frontend verhindern, also müsste das Speichern im Backend erfolgen. Ggf. hat ein solches Dokument zum fehlerfreien Schließen ein SaveOptions = "0" eingetragen, das im Falle des Speicherns im Backend ins Dokument gelangt und das zukünftige Speichern verhindert, wenn man es nicht wieder entfernt, usw.. Hier würde ich fast ein "Never" anbringen wollen, obwohl man ja nie nie sagen soll, und es auch Notwendigkeiten gibt, im Queryclose speichern zu müssen (Dateianhangshandling z.B., genau dabei hatte ich mal alle o.g. Problematiken zu lösen, und das alles in einer allgemeingültigen Teilmaske, ohne zu wissen, welche "Schweinereien" von anderen (zukünftigen, kundenindividuellen) Teilmasken verursacht werden, was die Sache nicht einfacher machte).
Um es kurz zu machen: Sowas würde ich nicht jemandem empfehlen, der "auch schon ein bisschen LotusScript programmiert" hat, denn schließlich soll das Resultat von der/demjenigen auch verstanden und bewältigt werden können.
Zu Historien ganz allgemein: Um wirklich eine genaue Historie darzustellen, baue ich Dokumente so, dass sie freigegeben werden müssen. Erst dann sind sie gültig und können im System verwendet werden. Diese Dokumente sind nicht mehr von Benutzern änderbar. Änderungen erfolgen, in dem man eine neue Version des Dokuments erstellt, mit Freigabe der neuen Version wird die alte Version ungültig (periodischer Agent, z.B. per agent.RunOnServer), verbleibt aber in der Datenbank. So kann ich später "durch die Zeit reisen" und jede Änderung des Dokuments nachvollziehen, vom Inhalt, vom Datum und vom Verursacher. Welchen Wert hat die Information, wer wann ein Feld zuletzt geändert hat, wenn es öfter geändert wurde und wenn ich nicht weiß, welchen Inhalt es vorher hatte?
Thema: Bearbeitung eines einzelnen Feldes festhalten à la "last edited by" (Gelesen 5642 mal)