Historie und Versionierung von Dokumenten

Das System versioniert Dokumente automatisch. Dadurch bleiben alle Änderungen am Dokument einsehbar, und Sie können im Notfall auf eine ältere Version des Dokuments zurückgreifen.

Manuell erstellte Kopien mit verschiedenen Versionsangaben wie die folgenden gehören der Vergangenheit an:

Dokument_V1.docx
Dokument_V2.docx
Dokument_V3.docx

Sie bearbeiten in agorum core automatisch immer die neueste Version eines Dokuments. Im Hintergrund entstehen automatisch Dokumentversionen, sobald Fälle eintreten, in denen das System eine solche Version automatisch erstellt:

Historie eines Dokuments

In der Abbildung Historie eines Dokuments wurde die Word-Datei Test 02.docx markiert. Im Detailfenster rechts unter der Registerkarte Objektinfo befindet sich der Abschnitt Historie. Hier erscheinen alle älteren und die aktuelle Version des markierten Dokuments /Objekts. Der oberste Eintrag stellt die aktuellste Version dar, mit der Sie derzeit arbeiten. Die älteren Dokumentversionen können Sie anschauen und bei Bedarf wiederherstellen.

Fälle, in denen Dokumente versioniert werden

Das System versioniert Dokumente in folgenden Fällen automatisch:

Der Inhalt ändert sich.
Die Metadaten des Dokuments ändern sich.
Der Dateiname ändert sich.
Die Dateibeschreibung ändert sich.

Diese Fälle sind von weiteren Situationen abhängig:

Benutzerwechsel: Der Benutzer, der das Dokument gerade bearbeitet, ist ein anderer Bearbeiter als in der aktuellen Version.
Während eine Datei gesperrt ist (so wie es Word bei der Bearbeitung macht), legt das System keine neuen Versionen an. Der gesamte Bearbeitungsvorgang vom Öffnen bis zum Schließen des Dokuments erzeugt genau eine Version mit dem Stand von vor Beginn der Bearbeitung. Die Sperre wird hier nur als Indikator verwendet, dass der Benutzer weiterhin mit derselben Bearbeitung beschäftigt ist.

Hinweise:

Textdateien werden bei der Bearbeitung nicht gesperrt. Andere Dokumente, etwa Word, HTML oder Excel werden häufiger kollaborativ bearbeitet und sind daher während der Bearbeitung gesperrt.
Wann eine neue Version in der Historie erstellt wird, ist abhängig vom eingestellten Zeitintervall für die Property NextHistoryTime.

Eine Version eines Dokuments wiederherstellen

Markieren Sie im Suchergebnis oder im agorum core explorer ein Dokument.
Öffnen Sie rechts im Detailfenster die Registerkarte Objektinfo.
Klicken Sie im Abschnitt Historie die herzustellende Version Ihres Dokuments mit der rechten Maustaste an.
Klicken Sie im Kontextmenü auf Historie wiederherstellen.

Ergebnis: Das System erzeugt einen neuen Eintrag in der Historie. Hierbei handelt es sich um die wiederhergestellte Version.

Speicherbedarf

Das System legt stets eine komplette Kopie des Dokumentinhalts an. Sofern innerhalb der Datenbank gespeichert wird, wird somit der komplette Speicherplatz belegt, wenngleich sich der Inhalt nicht oder nur teilweise ändert.

Wird das Zusatzmodul agorum core storage mit Deduplizierung verwendet, speichert das System gleichbleibende Blöcke innerhalb des Dokuments nicht erneut, sondern verweist nur darauf. Somit verbrauchen versionierte Dokumente, bei denen sich der Inhalt nicht ändert, fast keinen weiteren Speicherplatz.

Maximale Anzahl von Versionen

Das System erstellt im Standard unbegrenzt viele Versionen eines Dokuments (MaxHistoryCounter=-1). In älteren Versionen (vor 9.0.5) war der Standardwert auf 10 Versionen limitiert. Dieses Verhalten kann individuell eingestellt werden.

Erster Eintrag in der Historie (Originaldokument)

Um die Revisionssicherheit zu gewährleisten, legt das System bei der ersten Änderung eine Version eines Dokuments an, um dessen Originalzustand zu dokumentieren. Diese erste Historie hat eine Sonderstellung und ist permanent geschützt. Sie wird auch niemals durch neuere Versionen überschrieben oder automatisch gelöscht.

Hinweis: Dieser Schutz des Originaldokuments ist aus rechtlichen Gründen erforderlich, insbesondere für die Einhaltung der GoBD-Richtlinien (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form).

In der MetaDB existiert die Einstellung MaxHistoryCounter, mit der Sie das Verhalten der Historisierung steuern können. Wenn Sie die Historie verwenden möchten, um zu einer Vorgängerversion zurückkehren zu können, bleiben Sie bei der Standardeinstellung oder wählen Sie für MaxHistoryCounter mindestens den Wert 2, um sicherzustellen, dass Sie neben dem geschützten Originaldokument auf den aktuellen Arbeitsversionsverlauf zugreifen können.

Historie einstellen

Für die Historie existieren in der MetaDB diverse Einstellungen (Property-Entrys), mit denen Sie als Administrator die Historie individuell anpassen können.

Öffnen Sie links in der Seitenleiste Administration und dann MetaDB.

Öffnen Sie den Pfad:

/MAIN_MODULE_MANAGEMENT/roi/control/changeHistory

Ändern Sie die Property-Entrys.

Property-Entrys

Property-Entry	Beschreibung
ExcludeIdList	Führt Objekt-IDs von Objekten auf, die das System NICHT historisiert. Standard deaktiviert (durch # vor dem Property-Entry)
FirstHistoryAfterCreate	Definiert die Zeit in Sekunden, wann das System nach dem Erstellen eines Dokuments die erste Historie erstellt. Führt ein anderer Benutzer als der Ersteller eine Änderung vor Ablauf dieser Zeit durch, so erstellt das System sofort eine Historie. Standard 60
HistoryClassNames	Definiert die ClassNames der Objekte, die das System historisiert. Achtung: Störungen im Systembetrieb möglich. Eine Änderung dieses Werts führt zu unvorhergesehenen Fehlern. Ändern Sie nicht ohne Absprache diesen Wert, da parallel zu diesem Eintrag die entsprechende Programmierung im Kern von agorum core durchgeführt werden muss. Standard FileObject
MaxHistoryCounter	Definiert die Anzahl der Historien, die das System maximal pro Objekt erstellt. Die Werte -1 und 0 deaktivieren das Löschen von Versionen, wodurch unbegrenzt viele Versionen eines Dokuments angelegt werden können. Der Minimalwert für die Verwaltung einer begrenzten Anzahl von Historien ist 1. Durch diese Einstellung wird gewährleistet, dass das Originaldokument (erste Version) immer im System verbleibt. Sie haben bei diesem Wert darüber hinaus keine Möglichkeit zur Historienverwaltung. Werte ab 2 ermöglichen das Zurückkehren zu Vorgängerversionen. Bei 2 werden das Originaldokument und eine aktuelle Arbeitsversion gespeichert. Bei höheren Werten beginnt bei Erreichen dieses Limits ein Rotationssystem nach dem Prinzip First In, First Out. Das bedeutet, dass beim Erstellen einer neuen Version die älteste löschbare Version automatisch entfernt wird. Die erste Version (Originaldokument) ist immer geschützt und wird niemals gelöscht. Hinweis: Eine Reduzierung des MaxHistoryCounter-Werts löscht keine bestehenden Historien. Wenn ein Dokument bereits 10 Historien besitzt und Sie den Wert 2 setzen, bleiben alle 10 Historien erhalten. Das neue Limit greift bei der Bearbeitung von Dokumenten, die den MaxHistoryCounter-Schwellwert von Versionen noch nicht erreicht haben. Achtung: Volle Festplatte möglich. Sollten Sie das Modul agorum core storage nicht verwenden, kann sich der Speicherbedarf erhöhen und die Festplatte volllaufen, da das System für jede Historienversion eine Kopie des Dokuments erstellt. Standard -1 (unbegrenzt)
NextHistoryTime	Definiert die Zeit in Sekunden, bis das System eine neue Historie während einer Dokumentbearbeitung erstellt. Dies geschieht, sobald sich der Inhalt, Metadaten, Dateiname oder Dateibeschreibung ändert. Findet während der Dokumentbearbeitung ein Benutzerwechsel statt, greift die vorgegebene Zeiteinheit nicht. Stattdessen erstellt das System sofort eine neue Version, auch wenn die nächste NextHistoryTime noch nicht erreicht wurde. Der Parameter NextHistoryTime greift, wenn ein und dieselbe Person ein Dokument bearbeitet, dieses schließt und nach Ablauf der NextHistoryTime das Dokument erneut öffnet, um dieses zu bearbeiten. Standard 60
NotObjectNameForHistory	Definiert die RegularExpression für alle Dateinamen an, die das System NICHT historisiert. Ein ! als erstes Zeichen wirkt wie ein NOT. Standard String[] String[0]: '!.\..' String[1]: '.\.mdb' String[2]: '~.'
PrivateWorkingCopyFolder	Hinweis: Dieses Property-Entry ist aus Kompatibilitätsgründen für ältere CheckIn-/CheckoutOut-Verfahren enthalten. Verwenden Sie es nicht mehr. Definiert den Ordner, den nur der Benutzer sieht. Diesen MetaDB-Eintrag können Sie per JavaScript-API auslesen und dann darin verwenden. Beispiel hierfür wäre die CheckOut-Funktion, die dann das ausgecheckte Dokument dorthin ablegt. Dieses Feld können Sie für eine Konfiguration verwenden. Standard '${USER_HOME}/MyFiles/In Bearbeitung' Anwendungsbeispiel in der Java-API // Ein Objekt anhand der ID holen`let pwcf = objects.find('12121212').getPWCFolder(sc);`
VersionNumberAttribute	Anmerkung: Dieses Feld kann nur durch die Anbindung in der Konfiguration greifen und hat alleine keinen Effekt. Sobald Sie VersionNumberAttributeEnabled aktiviert haben, wird dieser Parameter aktiv. Als Wert tragen Sie den internen Namen eines Metadatums ein. Der Wert des Metadatums wird bei Objekten am Ende des Anzeigenamens (displayName) in Klammern mit angezeigt. Beim Check-In von Objekten wird dieses Metadatum automatisch passend inkrementiert. Standard VersionNumber
VersionNumberAttributeEnabled	Definiert den Parameter, um das Propert-Entry VersionNumberAttribute zu aktivieren. Dieses Feld können Sie für eine Konfiguration verwenden. Standard false
CheckinCommentAttribute	Anmerkung: Dieses Feld kann nur durch die Anbindung in der Konfiguration greifen und hat alleine keinen Effekt. Sobald Sie VersionNumberAttributeEnabled aktiviert haben, kann auch dieser Parameter eingesetzt werden. Als Wert tragen Sie den internen Namen eines Metadatums ein. Dieser erfasst beim Check-In den eingegebenen Kommentar.

Einstellungen „Description“ und „MaxHistoryCounter“

Diese beiden Einstellungen befinden sich im Property-Bundle sample-extension und ermöglichen es, für bestimmte Dateiendungen gesonderte, vom Standard abweichende Property-Entry-Einstellungen vorzunehmen:

Einstellungen Description und MaxHistoryCounter

Nachfolgendes Beispiel verdeutlicht die Verwendung dieser beiden Einstellungen.

Ziel

Für docx-Dateien soll ein anderer Wert für MaxHistoryCounter verwendet werden, als im Standard vorhanden ist.

Umsetzung

Kopieren Sie das vorhandene Property-Bundle sample-extension und fügen Sie es an derselben Stelle wieder ein.
Benennen Sie die Kopie in den Namen der Extension um:
```
docx
```
Bearbeiten Sie das Property-Entry MaxHistoryCounter in diesem neuen Property-Bundle docx und tragen Sie den gewünschten Wert ein.

Beispiel
```
3
```

Ergebnis

Ab sofort speichert das System für alle docx-Dateien lediglich maximal 3 Historien. Das neue Limit greift jedoch nur bei Dokumenten, die noch nicht die angegebene Anzahl von erstellten Historien erreicht haben.

Wenn für MaxHistoryCounter der Wert 10 eingestellt ist und Sie nachträglich für docx-Dokumente den Wert 3 einstellen, bleiben bereits vorhandene Historien erhalten.
Wenn Sie ein Dokument ändern, das bereits 10 Historien hat, bleibt es bei der Anzahl von 10 Historien. Die neue Historie wird angelegt und die jeweils älteste, löschbare Version entfernt.
Wenn Sie Dokumente bearbeiten, die zum Zeitpunkt der Änderung noch weniger als die neu angegebene Anzahl von 3 Historien hatten, werden für diese Dokumente nicht mehr als insgesamt 3 Historien erstellt und bei Erreichen des Limits 3 die jeweils älteste, löschbare Version entfernt.

Sind keine abweichenden Konfigurationen für bestimmte Dateitypen und Parameter definiert, gelten die Standardwerte.