Write protection within workflows

When a (context-dependent) workflow is started, write protection can be applied to the element where the workflow was started (see Status properties page). The purpose of this write protection is to prevent an element from being changed by another editor while a workflow is running.

Write protection by means of running workflow instances
The write protection affects the current object and all subordinate objects of the running instance of the workflow. In the example, write protection is applied to the “Marketing” folder by means of a running workflow. If another user tries to lock this folder so that he or she can edit it, he or she will be informed that this element cannot currently be edited. The same message also appears if the user tries to lock the “Company” folder or any object under the “Marketing” folder.

The write protection is set independently of whether a script is used by the workflow and the actions that are run on the affected element.

Write protection when creating and moving

Within SiteArchitect, some actions can be performed without the object having to be in editing mode. This change was made to the editing concept so that work involving multiple users at the same time can run as smoothly as possible, even in the case of large projects with lots of users. This means, for example, that it is no longer necessary to request the entire subtree in order to edit an element; instead, only the object that is about to be changed is required. Similarly, it is also possible to create or move an element without first having to request write protection for the parent node (editing mode).

However, given that workflows involve potentially critical actions (e.g. release of an object), write protection of a workflow also prevents creation or movement within the instance of the workflow that is currently running.   

If, for example, an editor tries to add a section to a page on which a workflow has just been started, an error message is displayed.

Write protection within scripts

For some actions that are run via the FirstSpirit Access API, write protection must be applied to the affected element, such as:

• Recursive deletion of elements in the project
• (Recursive) release of elements in the project

One particular problem that is encountered in practice occurs when write protection is applied in a script (to an element or subtree – API call setLock(true, false) or setLock(true)), but write protection has already been applied to the element as a result of the workflow being started. In this case, the write protection of the workflow prevents the “normal” write protection being applied to the element.

However, it is not actually necessary to set the write protection for simple delete or release actions within the workflow, because the affected element is already locked automatically by the workflow as soon as the transition is switched.

It is different if the deletion or release is recursive; in other words, if it is to be run on a subtree of the project. In this case, recursive write protection has to be applied to the entire subtree and this is only possible if the write protection of the workflow is turned off. This involves temporarily removing the (automatically set) write protection via the workflow state and reapplying it on completion of the delete or release operation (via the script). The exact procedure is described in the “Tutorials” chapter using RecursiveLock as an example.