Domino 9 und frühere Versionen > ND8: Entwicklung

DocumentUniqueID wird beim Kopieren nicht neu gesetzt

<< < (2/2)

Peter Klett:
Das ist aber doch logisch, wie sollte Notes "von selbst" das ändern?

Angenommen Du kopierst ein Mitarbeiterdokument, bei dem der Name "Meier" steht. Das neue Dokument soll aber den Namen "Müller" bekommen, da musst Du das auch von Hand anpassen. Es ist schließlich nur ein ganz normales Item in dem Dokument, das kopiert wird.

In Deinem Fall ist es so, dass sich der Inhalt des Feldes aus einer Eigenschaft des Dokumentes berechnet. Da kannst Du einfach generell einen Agenten laufen lassen, der das bereinigt

FIELD MeinFeld := @Text (@DocumentUniqueID)

Wie ist denn das Feld in der Maske definiert? Berechnet biem Anlegen? Du kannst es auch auf "Berechnet" stellen, denn derjenige, der ein Dokument kopiert, wird es danach doch wohl noch anpassen wollen, und beim Speichern wird dann die richtige ID gespeichert (sofern das neue Dokument bearbeitet wird, und nicht das alte).

Das Verhalten ist für mich völlig natürlich. Du nutzt eine Steuerung außerhalb der Notes-Standard-Eigenschaften, dann musst Du die auch selbst verwalten.

Wir machen in unseren Systemen übrigens genau das gleiche, dort haben wir auch Felder, in denen die ID des Dokumentes gespeichert ist, und es gab auch einen Grund dazu, weshalb wir das gemacht haben (ist aber schon sehr lange her). In unseren Anwendungen verbieten wir, Dokumente per Zwischenablage einzufügen. Wenn doch eine Kopie eines Dokuments benötigt wird, gibt es einen Kopie-Button, mit dem eine Kopie des markierten Dokuments erstellt und dieses geöffnet wird. So hat ein gespeichertes Dokument immer die richtige ID gespeichert. Und für Admins, die auch über die Zwischenablage kopieren dürfen, gibt es ein SmartIcon, um das Feld zu korrigieren.

iukhdh:
Klar ist das im Grunde logisch, dass der Inhalt mit kopiert wird.
Daher ja auch meine Frage ganz oben, wie ich es schaffe, das Dokument gleich beim Einfügen wieder zu aktualisieren.
Da das Feld mit der UniqueID auf "berechnet" gestellt ist, wäre dann dieses Problem behoben.

Das Kopieren zu unterbinden habe ich in einer anderen DB auch schon eingesetzt, sollte kein Problem sein.

Aber es hätte ja vielleicht auch eine elegantere Lösung geben können, die mir  nicht geläufig ist.
Und zumindest die Sache mit dem PostPaste Event in der Ansicht war schonmal was neues für mich.

Und du hast natürlich Recht, in der Regel wird das neue Dokument noch bearbeitet werden müssen, da sich doch ein paar Daten im neuen Dokument immer ändern.

Peter Klett:

--- Zitat von: iukhdh am 28.07.15 - 12:06:56 ---... Und du hast natürlich Recht, in der Regel wird das neue Dokument noch bearbeitet werden müssen, da sich doch ein paar Daten im neuen Dokument immer ändern.

--- Ende Zitat ---
Aber die Wahrscheinlichkeit ist hoch, dass nach dem Kopieren das alte Dokument geändert wird, da man i.d.R. als Endanwender nicht erkennen kann, welches Dokument das neue ist, und dann hat das neue ungeänderte Dokument die falsche ID

Driri:
Ich würde Dir empfehlen, von dem PostSave-Event in den Ansichten Abstand zu nehmen. Wenn neue Ansichten dazukommen, mußt Du immer daran denken und dann hast Du immer noch das Problem, daß sich ggf. Anwender private Ansichten erstellen.

Sauber bekommst Du das in meinen Augen nur hin, wenn Du das so wie Peter es skizziert hat machst. Oder Alternativ dir noch mal Gedanken beim Anlegen neuer "Antwort"-Dokumente machst.

cg-home:
da hat Peter Recht, ist uns auch schon oft so gegangen, dass dann das "alte" Dok verändert wurde
und wenn da z.B.: schon Antworten drang hingen, ist das Chaos perfekt.
Bei so heiklen DBs unterbinden wir das Kopieren generell oder machen es auch über eine Aktion.
Oder über einen Agenten getriggert auf das Ereignis "Wenn Dokumente eingefügt werden", das
spart uns die Anpassung aller Ansichten.
Darüber schreiben wir dann noch im Titel oder Subject ein " - Kopie" mit Datumscode, die Historie
geleert und befüllt mit "Kopiert von .... am ..... " usw.
Somit ist für den Benutzer ersichtlich welches die Kopie ist.

Gruß Christian

Navigation

[0] Themen-Index

[*] Vorherige Sete