Domino 9 und frühere Versionen > ND8: Entwicklung

Bearbeitung eines einzelnen Feldes festhalten à la "last edited by"

<< < (2/3) > >>

koehlerbv:
Prinzipielle Zustimmung insofern, dass Replizierkonflikte und Aushebeln des Mischens von Replizierkonflikten minmiert werden, wenn geändertes Feld und zwangsweise anhängendes Historienfeld gekoppelt sind.

Ich habe aber wieder einen A-Bär:
On Change: Never! Das hat mit der abschliessenden Speicherung nichts zu tun. Selbst die Speicherung an sich muss nicht aussagekräftig sein, da es ja durchaus helle User gibt, die zwischenspeichern.

Daher mein Vorschlag:
1) Zu den betreffenden Feldern gibt es EIN History-Field mit Wer und wann (wozu zwei?)
2) Das ganze passiert mindestens erst beim Speichern (QuerySave). Das geht auch noch mit @Functions ("schön" ist aber in diesem Fall etwas anderes)
3) Besser: Das passiert durch vorher / nachher_Vergleich (PostOpen / QueryClose) erst, wenn das Dokument im Frontend gespeichert wurde und am Schliessen ist (QueryClose).
4) Noch besser: Das ganze ist als Routine ausgelagert, dass es auch Agents verwenden können 8an Entwickler: MÜSSEN), wenn Änderungen im Backend passieren.

Völlig ausgeklammert habe ich hier den Hintergrund / die Notwendigkeit etc. dieser Protokollierung. Dies wird sicher in jedem Anwendungsfall anders aussehen. Ich kenne derartige Anwendungsfälle in erster Linie in Zusammenhängen, wo man wer / wann /warum erkennen muss und ich hierzu Felder überwachen muss (zum Beispiel Urlaubskontingente: Warum hat Mitarbeiter X auf einmal in 2011 33 Tage Urlaub, in 2012 aber nur 27? Weil er per Sondervereinbarung seinen Urlaub wegen Streik verlängern durfte und sich aus dem 2012er Kontingent bedienen durfte).

Soweit meine 2ct.

Bernhard

Peter Klett:
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?

Grinsekatze:
Wow - es ist ja unglaublich wie schnell man hier ausführliche Antworten bekommt!
Erst einmal ganz herzlichen Dank an alle, die sich zum Thema geäußert haben.

Das einzige Problem ist, dass ich nur die Hälfte eurer Antworten versteh. Ich stell gerade fest, dass ich wohl doch nur einen kleinen Bruchteil von dem was ich dachte wohl wirklich kann.

Ich habe gestern nochmal mit meiner Chefin über die Anforderung gesprochen und sie meinte, dass sie eigentlich doch ganz gerne das mit der History Class umgesetzt hätte, nachdem ich ihr davon erzählt habe.
Also dachte ich "Super, da hats 'ne schöne Anleitung, das bekommst du hin."
Aber weit gefehlt...

Da es den Anschein hat, als sei die History Klasse von Michael Wöhr hier einigen ein Begriff erzähl ich einfach mal, wo's hakt...

Also ich habe die Anleitung mit den sechs Schritten so weit befolgt und bekomme in meiner Script Library auch keine Fehler angezeigt.

Allerdings hängt es bei mir gerade irgendwie bei der Sache mit dem History-Textfeld an sich im Dokument. Ich weiß einfach nicht, was ich als "value" eintragen muss (das ganze ist ja ein "computed when composed"-Feld, also muss da ja wohl irgendeine Formel rein, die die Funktion aufruft oder ähnliches?).
Zudem beschleicht mich die leise Vermutung, dass man im Code an sich vielleicht ja auch noch irgendwelche Änderungen machen muss... sollte dies der Fall sein, welche?

Würde mich über jegliche Ratschläge freuen!
Solltet ihr der Meinung sein, dass mir bei solchen Wissenslücken nicht zu helfen ist, dann würde ich an der von euch beschriebenen Umsetzung mit Formelsprache versuchen und das muss dann eben doch ausreichen.

Liebe Grüße,
Sarah

Grinsekatze:
Nachtrag:
Hab gerade wohl wirklich an einer Hirnblockade gelitten... Das mit dem "value" des Textfelds hat sich erledigt!

Jetzt zeigt es mir immerhin schon an, wann ich das Dokument erstellt habe :)

Driri:
Damit dann auch Änderungen an bestimmten Felder dokumentiert werden, mußt Du im Postopen der Maske noch tätig werden. Das sollte aber in der Anleitung beschrieben sein.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete