Eingebaute Versionskontrolle von Lotus

[MadMetzger]

Ich denke gerade darüber nach, wie ich das Aufbewahren alter Versionen von Dokumenten realisiere. Dazu gibt es ja bei Domino-Anwendungen standardmäßig die Möglichkeit, dies über das Feld $VersionOpt zu steuern und den Rest Notes zu überlassen. Finde ich schonmal ganz gut, da man dann das Rad ja nicht zweimal erfinden muss.

Nun frage ich mich aber, ob diese Versionskontrolle auch funktioniert, wenn ich im Backend mit Dokumenten arbeite? Oder arbeitet die Versionskontrolle nur im Frontend?

Im letzteren Fall müsste ich für eine Anwendung von mir das wohl selbst implementieren. Kann jetzt zwar noch nicht absehen, wie aufwändig das wird, aber machbar ist das bestimmt auch...

[MadMetzger]

Ich habe parallell selbst nochmal ein bißchen getestet. Aber irgendwie ist mir die Funktionsweise noch nicht ganz klar.

Die Versionskontrolle zieht nicht im Backend, also muss man da selbst tätig werden. Auch im Frontend tut sie nicht das, was ich erwartet hätte. Die Antworten werden nicht in einer Art Kette von Antworten gespeichert, sondern alle Vorgängerversionen sind Geschwister.

[Wiesel]

Hallo!
Ich stehe im Moment vor einem ähnlichen Problem und wollte mal anfragen, ob Du für mich eine Lösung hast.

Wir haben eine Datenbank im Einsatz, in der in der Maskeneigenschaft die automatische Versionskontrolle eingeschaltet ist.

Nun habe ich eine Massendatenänderung in die Datenbank eingebaut. Mit Auswahl und Prüfung der eingegebenen Daten und Pflege der Dokumentation in dem Dokument selbst.

Durch die Massendatenänderung passiert genau das, was Du beschrieben hast. Nix. Keine Versionserstellung. Die brauchen wir aber zwingend. Nur wie implementiert man das nun?

Hast Du das was gefunden?

Grüße,
Wiesel

[koehlerbv]

Wie gut bist Du in LotusScript? Denn diese Funktion musst Du Dir im Backend selber nachbauen - eingebaut gibt es die Versionskontrolle nur im Frontend (und dazu dann noch in verschiedenen Varianten).

Im Endeffekt brauchst Du nichts anderes zu machen als Dir ein Dokument "neu" und eins "als Version" anzuschauen und die entsprechenden Items dann nachzubauen. Am besten machst Du das mit einer Spiel-DB, die nur ein oder zwei Felder in der verantwortlichen Maske mit Versionskontrolle enthält.

"Magic tricks" gibt es hierbei nicht. Alles handwerk.

Bernhard

[Wiesel]

LotusScirpt ist nicht gerade mein Steckenpferd.

Habe schon Versuche mit MakeResponse etc. versucht.
Und dazu muss das Ganze per Agent ja auch über die markierten Dokumente laufen.

Wie meinst Du das genau mit
"Dokument "neu" und eins "als Version" anzuschauen "
?

Wie sage ich denn dem "alten Dokument", dass es jetzt ein Antwortdokument ist?

[koehlerbv]

Wie meinst Du das genau mit
"Dokument "neu" und eins "als Version" anzuschauen "?

Mache eine Spiel-DB. Lege ein Dokument an. Mache es über das Frontend zu einer Version des neuen Dokuments. Schaue Dir dann die Items im Versionsdokument an. Ganz einfach.

LotusScirpt ist nicht gerade mein Steckenpferd.

Damit sinken Deine Chancen, das umzusetzen, ganz extrem.

Bernhard

[MadMetzger]

Leider habe ich damals nichts mehr dazu gefunden und kam dann auch, sofern ich mich recht erinnere, um eine Versionierung drumherum. Aber im Grunde ist sowas relativ leicht nachbaubar, wenn man weiß, was der Mechanismus tut.

Ich kann mich noch dran erinnern, dass beispielsweise das Form-Item nicht mit in die alten Versionen übernommen wurde. Alles weitere kann ich jetzt leider nicht mehr nachvollziehen.

[guesswho]

im Frontend geht das automatisch, im Backend nur manuell. Da muss man natürlich auch das Form-Item setzen.

Jo

[koehlerbv]

Nicht nur das Form-Item, Jo ... Aber das kann man ganz einfach selbst herausfinden.

Bernhard

[guesswho]

schrieb ja "auch..." 

jo

BTW: Ich finde das so perfekt, Frontend automatisch, Backend aber Sache des Programmierers. Gute Sache, so.

[koehlerbv]

Rischtisch. Das Frontend für einfache Sachen und das Backend selbst das Zepter in die Hand. Das ist genau das, was wir so schätzen.
Volle Zustimmung also, Jo!

Bernhard