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 neuste 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.

Hinweis: .txt-Dateien sperren sich bei Bearbeitung nicht, wodurch der genannte Indikator fehlt. Das System legt daher bei jeder Speicherung trotz geöffneter Datei eine neue Version an. Andere Dokumentarten, etwa Word, HTML oder Excel reagieren von Natur aus anders. Diese werden bei Bearbeitung gesperrt, sodass die Version nicht bei jeder Speicherung eines aktuell bearbeiteten Dokuments greift, sondern erst, wenn diese Datei geschlossen und nach Ablauf der vom Administrator einstellbaren NextHistoryTime erneut bearbeitet wird.

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

Im Standard erstellt das System unendlich viele Versionen eines Dokuments. 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 wird auch nicht durch neuere Versionen überschrieben.

In der MetaDB existiert die Einstellung MaxHistoryCounter, mit der Sie dieses Verhalten steuern können. Wenn Sie die Historie verwenden möchten, um zu einer Vorgängerversion zurückkehren zu können, wählen Sie für MaxHistoryCounter mindestens den Wert 2, da Sie sonst keine neuen Versionen erfassen 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. Der Wert -1 deaktiviert das Löschen von Versionen, wodurch unbegrenzt viele Versionen eines Dokuments angelegt werden können. Sollten Sie diesen Standardwert abändern und etwa definieren, dass nur 20 Versionen angelegt werden dürfen, beginnt ein Rotationssystem. Das bedeutet, dass bei einer neuen Version die zweitälteste gelöscht wird. Die erste Version darf aus gesetzlichen Gründen nicht gelöscht werden. Wenn Sie die Historie verwenden möchten, um zu einer Vorgängerversion zurückkehren zu können, wählen Sie für MaxHistoryCounter mindestens den Wert 2, da Sie sonst keine neuen Versionen erfassen können. 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
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 3 Historien. Aktivieren Sie diese Funktion nachträglich, passt das System die Historien entsprechend bei der ersten Änderung eines passenden Dokumententyps nach Aktivierung an.

Wenn im Standard also für MaxHistoryCounter der Wert 10 eingestellt ist und Sie nachträglich für docx-Dokumente den Wert 3 einstellen, löscht das System die überschüssigen Historien beim Erstellen einer neuen Version.

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

Open Source DokumentenmanagementDokumentation