Letzter Author in ein Feld eintragen

[LotusBleifrei]

Hallo,

ich denke mal wieder ein einfaches Ding für euch.
Ich habe ein Feld, in diesem Feld wird der Author eingetragen der zuletzt etwas in der Maske abgespeichert hat.

Nun kann ich ja für das Feld einen Typ eintragen:
Typ: Author => Berechnet zur Anzeige

danach trage ich noch den Wert für das Feld @Author ein!

Sobald ich einen neuen Eintrag über diese Maske mache, dann trägt er mir auch fein und richtig den Author ein!

Aber sobald ich einen vorhandenen Datensatz öffne und bearbeite und anschliessend speichere dann wird der zuletzt genannte nicht Angezeigt es steht immer noch der Ersteller im Feld. Ich würde aber gerne die Person drinstehen haben die zuletzt etwas verändert hat am Datensatz.

Was muss ich verändern am Feld?

MfG Deny

[Semeaphoros]

1. Berechnet zur Anzeige speichert den Wert nicht ab

2. @Author sucht sich den Wert im Dokument zusammen, schau Dir mal die Designer-Hilfe zu dieser Funktion an, da steht genau, was zurückkommt.

3. Wenn Du protokollieren willst, wer das Dokument bearbeitet hat, dann tue das, indem Du den gegenwärtigen Benutzer (@Username) im QuerySave in eine Liste einträgst und diese mit abspeicherst.

[HarryB]

Die Information muss nicht gesondert abgespeichert werden, da sie in dem Feld "$UpdatedBy" automatisch mitgeführt wird. Der Zugriff sollte über ein Feld erfolgen, welches nur zur Ansicht berechnet wird:

@If($UpdatedBy = "";@Name([CN];@UserName);@Subset($UpdatedBy;-1))

Da das Feld "$UpdatedBy" erst gefüllt wird, wenn das Dokument tatsächlich eine Revision erhält (sprich: ein vorhandenes Dokument wird erneut abgespeichert), erfolgt die Unterscheidung ob das Feld leer ist oder nicht.

Viele Grüße
Harry

[Semeaphoros]

Das stimmt nur bedingt, schau mal in der Designer-Hilfe den Eintrag zu $UpdatedBy an.

[Glombi]

$UpdatedBy hat den Vorteil, dass damit auch der "wirkliche" Autor der letzten Änderung angezeigt wird. Wenn man mit Feldern und Querysave arbeitet, bekommt man es auf diese Weise nicht mit, wenn das Dokument von außen - bspw. per Agent oder Backendscript - geändert wurde.
Im dem Zusammenhang sei auch noch $Revisions genannt.
Leider gibt es zwischen beiden keine eindeutige Beziehung.
Aber die jeweils letzten Einträge der beiden Items liefern Name und Zeitpunkt zurück - ausser man ist in der Maske und speichert. Dann wird es nicht korrekt angezeigt.

Andreas

[Semeaphoros]

Das braucht in jedem Fall ein Author-Feld, damit es wirklich tut, wie man es erwartet.

Ansonsten, wenn man vom System die gewünschten Auskünfte bekommt, sollte man das natürlich nutzen.

[koehlerbv]

$UpdatedBy würde ich auch bevorzugen - es sei denn, man will maschinelle Änderungen ausblenden.
Wozu braucht es aber ein Autorenfeld ? Ein berechnetes Feld vom Typ Text tut es doch auch ...

Bernhard

[Semeaphoros]

Weil Domino das Feld sonst nicht wirklich nachführt. Siehe Hilfe

[HarryB]

@Semeaphoros

Die Hilfe sagt leider nur die halbe Wahrheit. Das Feld "$UpDatedBy" wird auch ohne Existenz eines Autorenfeldes in der Maske gefüllt.

Nachteil der Funktion @Authors ist, dass diese die Autorenfelder zurückgibt, so diese denn vorhanden sind, unabhängig davon, ob diese tatsächlich das Dokument bearbeitet haben oder nicht.

Viele Grüße
Harry

[Semeaphoros]

Es wird gefüllt, aber wie ich mal schmerzlich feststellen musste, nicht zuverlässig nachgeführt. Frag mich nicht, nach welchen Kriterien das Feld gefüllt wird, wenn kein Autor-Felf vorhanden ist, ein wirkliches Rekonstruieren ist jedenfalls ohne ein Autor-Feld im Dok nicht möglich. Nebst dem Problem, dass man den Zeitpunkt nicht dazu bekommt

[koehlerbv]

@Jens:
Nachführen bei Namensänderungen meinst Du ? Wenn dies denn gewünscht ist. Wenn, dann muss natürlich der Feldtyp "Autoren" sein.

@Harry:
Vorsichtig bei @Authors: Das kann man in diesem Zusammenhang überhaupt nicht verwenden. Und: Die Funktion gibt den Inhalt des *ersten* Autorenfeldes wieder (zumindest in R5)

Bernhard

[Semeaphoros]

Nein, nein, nicht bei Namensänderung. Nicht jedes Speichern (mit neuen Werten!) führt zu einem Nachtrag in $UpdatedBy, ausser wenn ein Autor-Feld drin ist. Daher auch der Text in der Hilfe. Damit ist das Feld in einem Dok ohne Zugriffssteuerung simpel nicht "History-Fähig".

Anders ausgedrückt: Die Designer-Hilfe hat guten Grund, das so zu schreiben, wie sie es schreiben, auch wenn sie keine Begründung dazu geben --- leider

[koehlerbv]

Darüber bin ich noch gestolpert ... Man lernt eben dauernd noch dazu  
Andererseits hatte ich mit $UpdatedBy noch nie ein Problem. Von nun an werde ich das aber mit äusserster Vorsichtig geniessen !

Merci,
Bernhard

[HarryB]

@Harry:
Vorsichtig bei @Authors: Das kann man in diesem Zusammenhang überhaupt nicht verwenden. Und: Die Funktion gibt den Inhalt des *ersten* Autorenfeldes wieder (zumindest in R5)

Bernhard

Würde ich auch nie tun! Wie kommst du darauf?

Viele Grüße
Harry

[Semeaphoros]

Das ist mir zum Glück ziemlich früh mal passiert, dass ich glaubte, $UpdatedBy sei zuverlässig. Dann stellten wir mal fest, dass zwei Sachbearbeiter es nicht gewesen sein wollten, die sich nicht an die Konventionen gehalten haben, und es hätte nicht viel gefehlt, dass sie sich gegenseitig dauernd das Zeugs "korrigiert" hätten. Na ja, da stellte sich dann heraus, dass wir nicht zuverlässig feststellen konnten, wer den aktuellen Zustand abgespeichert hatte ...... Seitdem ......

[HarryB]

Nein, nein, nicht bei Namensänderung. Nicht jedes Speichern (mit neuen Werten!) führt zu einem Nachtrag in $UpdatedBy, ausser wenn ein Autor-Feld drin ist. Daher auch der Text in der Hilfe. Damit ist das Feld in einem Dok ohne Zugriffssteuerung simpel nicht "History-Fähig".

Anders ausgedrückt: Die Designer-Hilfe hat guten Grund, das so zu schreiben, wie sie es schreiben, auch wenn sie keine Begründung dazu geben --- leider

Allerdings stellt sich mir in diesem Zusammenhang die Frage, woher die LotusScript Eigenschaft "Authors" der NotesDocument Klasse ihre Informationen holt, wenn nicht aus dem $UpdatedBy-Feld. Ich glaube nicht an ein mysteriöses, von dem Benutzer nicht zugreifbares Feld, welches die gewünschten Informationen zuverlässig speichert. Die Redundanzen wären enorm und würden Performanceeinbrüche erzeugen, die nicht vertretbar wären.

Nach meiner Beobachtung passiert mit den Feldern "$UpdatedBy" und "$Revisions" folgendes: "$Revisions" wird bei jedem Speichern mit einem neuen Zeitstempel versehen. "$UpdatedBy" wird aktualisiert, wenn der aktuelle Bearbeiter nicht der letzte Bearbeiter ist. Das Problem bei diese Vorgehensweise ist, dass man zuverlässig nur den letzten Bearbeiter und die letzte Version abfragen kann. Eine echte Historie lässt sich daraus nicht ableiten.

Wenn du eine echte Historie mit allen Bearbeitern zu dem jeweils zugehörigen Speicherdatum haben willst, musst du wirklich eigene Felder mitführen. Hierzu sind Autorenfelder aber nur dann sinnvoll, wenn das Dokument und die Datenbank mit Hilfe von Autorenfeldern Zugriffsrechte festlegt. Ansonsten würde ich Textfelder mit Mehrfachwerten bevorzugen.

Viele Grüße
Harry

[Semeaphoros]

Kann nicht sein, der letzte Bearbeiter steht nicht immer an letzter Stelle im $UpdatedBy Feld. Das war ja genau das, was wir feststellen mussten, der letzte Bearbeiter lässt sich nicht zuverlässig feststellen.

[HarryB]

Kann nicht sein, der letzte Bearbeiter steht nicht immer an letzter Stelle im $UpdatedBy Feld. Das war ja genau das, was wir feststellen mussten, der letzte Bearbeiter lässt sich nicht zuverlässig feststellen.

Dann stellen sich mir die folgenden Fragen:

1. Arbeitet die Eigenschaft "Authors" der Klasse "NotesDocument" zuverlässig?
2. Falls ja, wo holt sie ihre Informationen her?

Viele Grüße
Harry

[Semeaphoros]

Zuerst stellt sich die Frage, ob alle Bearbeiter im $UpdatedBy vorhanden sind oder nicht. Das weiss ich tatsächlich nicht mehr.

Dann stellen sich tatsächlich die Fragen, die Du hier aufgeführt hast.

Ich weiss es nicht, weil ich dort, wo es nötig ist, eine eigen History führe, das auch deshalb, weil bei $UpdatedBy ja auch kein Zeitpunkt dabei steht, und der ist manchmal wichtig.