Schreibschutz innerhalb von Arbeitsabläufen
Beim Starten eines (kontextgebundenen) Arbeitsablaufs kann das Element, auf dem der Arbeitsablauf gestartet wurde, mit einem Schreibschutz versehen werden (siehe Seite Status Eigenschaften). Dieser Schreibschutz soll verhindern, dass ein Element von einem anderen Bearbeiter verändert wird, während ein Arbeitsablauf läuft.
Schreibschutz durch laufende Instanzen eines Arbeitsablaufs
Der Schreibschutz wirkt sich sowohl auf das aktuelle Objekt als auch auf alle untergeordneten Objekte der laufenden Instanz des Arbeitsablaufs aus. Im Beispiel ist auf dem Ordner „Marketing“ durch einen laufenden Arbeitsablauf ein Schreibschutz gesetzt. Versucht ein weiterer Benutzer, diesen Ordner zum Bearbeiten zu sperren, erhält er die Information, dass das Element aktuell nicht bearbeitet werden kann. Die gleiche Meldung erscheint auch, wenn der Benutzer versucht den Ordner „Unternehmen“ oder ein beliebiges Objekt unterhalb des Ordners „Marketing“ zu sperren.
Der Schreibschutz wird unabhängig davon gesetzt, ob der Arbeitsablauf ein Skript verwendet und welche Aktionen auf dem betreffenden Element ausgeführt werden.
Schreibschutz beim Anlegen und Verschieben
Innerhalb des SiteArchitect können einige Aktionen ausgeführt werden, ohne dass sich das Objekt im Bearbeitungsmodus befindet. Diese Änderung des Bearbeitungskonzepts soll dafür sorgen, dass auch in großen Projekten ein paralleles Arbeiten (mit vielen Benutzern) möglichst reibungslos funktioniert. So wird beispielsweise beim Bearbeiten eines Elements nicht mehr der gesamte Teilbaum zur Bearbeitung angefordert, sondern nur das Objekt, das aktuell geändert werden soll. Das Anlegen oder Verschieben eines Elements ist daher ebenfalls möglich, ohne zuvor den Schreibschutz auf dem Vaterknoten (Bearbeitungsmodus) anzufordern.
Da es sich bei Arbeitsabläufen jedoch um potentiell kritische Aktionen handelt (z. B. die Freigabe eines Objekts), unterbindet der Schreibschutz eines Arbeitsablaufs auch das Anlegen bzw. Verschieben innerhalb der aktuell laufenden Instanz des Arbeitsablaufs.
Versucht ein Redakteur beispielsweise einen Absatz zu einer Seite hinzuzufügen, auf der aktuell ein Arbeitsablauf gestartet wurde, wird eine Fehlermeldung angezeigt.
Schreibschutz innerhalb von Skripten
Für einige Aktionen, die über die Access-API von FirstSpirit ausgeführt werden, ist ein Schreibschutz auf dem betreffenden Element notwendig, z. B.:
- Rekursives Löschen von Elementen im Projekt
- (Rekursive) Freigabe von Elementen im Projekt
Ein Problem, das sich nun in der Praxis stellt, ist das Setzen eines Schreibschutzes in einem Skript (auf einem Element oder Teilbaum – API-Aufruf setLock(true, false) bzw. setLock(true)), wenn durch das Starten des Arbeitsablaufs bereits ein Schreibschutz auf dem Element besteht. Der Schreibschutz des Arbeitsablaufs verhindert in diesem Fall das Setzen des „normalen“ Schreibschutzes auf dem Element.
Für einfache Lösch- oder Freigabe-Aktionen innerhalb des Arbeitsablaufs ist das Setzen des Schreibschutzes allerdings nicht notwendig, da das betreffende Element beim Schalten der Transition ja bereits automatisch durch den Arbeitsablauf gesperrt ist.
Anders sieht es aus, wenn das Löschen oder Freigeben rekursiv, das heißt auf einem Teilbaum des Projekts ausgeführt werden soll. In diesem Fall muss ein rekursiver Schreibschutz auf dem kompletten Teilbaum gesetzt werden und das ist nur möglich, wenn der Schreibschutz des Arbeitsablaufs aufgehoben wird. Dazu wird der (automatisch gesetzte) Schreibschutz über den Status des Arbeitsablaufs temporär entfernt und beim Beenden der Lösch- bzw. Freigabe-Option (über das Skript) erneut gesetzt. Das genaue Vorgehen wird im Kapitel „Tutorials“ anhand des Beispiels RecursiveLock beschrieben.