Layer 2 – Lifecycles
In my previous article, I described the Vault security at the global level, the user and group accounts with their role assignments. Today, we discuss the security available by assigning a lifecycle to a file. I will also include using items, and compare how items handle this issue.
If you use Vault Workgroup or Vault Professional, the release management module is available to you. Release management consists of applying a lifecycle to a file, which also applies a lifecycle state. A lifecycle is defined as having one or more available states, with one particular state identified as the default state. When a file is assigned a lifecycle, the default state is also assigned to that file. That file is then controlled by the security defined in the lifecycle state.
Stepping back to look at the lifecycle definition, we can use the sample definition of the Flexible Release Process. There are five states defined for this lifecycle, with the Work in Progress state identified as the default. This means that any file assigned this lifecycle will be automatically put into the Work in Progress state. If I need to bulk load a large number of legacy files, for example when setting up a new vault, I may find it useful to temporarily set the default state to Released, if I simply need to get those files in the vault and I do not intend to make additional changes to those files.
Each state in the lifecycle has a number of settings associated with it. Focusing on the security aspect, each state has security settings (shown on the Security tab). This listing is called an Access Control List (ACL).
If the box is checked for ‘No state-based security’, then anyone with the global role of document editor (either level) can check this document out and make changes. In the above example, we limit the access. The ‘Everyone’ group is allowed to read the files, but cannot modify, even if they have the document editor role assigned. There are two groups that are allowed to modify and delete files, the Engineering and Administrators groups. If we compare this with the Released state, we see that the Released state denies Everyone the ability to modify or delete files.
One point to make here is the concept of implied versus explicit denial. In the Released state, we see that everyone has an explicit denial of modify and delete rights. If I were to add another group or user to this ACL and set modify to Allow, they would not be able to modify these files because the Everyone group is explicitly denied the ability to modify. Comparing this to the Work in Progress state above, the Everyone group is explicitly allowed to read the files, but there is an implicit denial to modify or delete these files, unless that user is also in one of the other groups that are explicitly given the modify privilege. All users are in the Everyone group, but only those users in the Engineering and Administrators group can modify, in the Work in Progress state. Generally speaking, when I set up a system, the Work in Progress and Quick-Change states allow some groups to edit and delete files. The For Review, Released, and Obsolete states are locked for everyone, since we typically want to keep the files in those states from being modified.
The other security included with the lifecycles controls the transitions, and specifies who is allowed to change from one state to another. Within the lifecycle definition, there is a definition the selected state to and from every other state.
If we edit the state transitions, we again see a security tab with an Access Control List (ACL) that allows us to define who is allowed to or denied from making that transition. In the example below, the Administrators and Engineering groups are allowed to change the state of a file from Work in Progress to For Review. Anyone not in either of those two groups will not be allowed to make that transition. Again, there is a check box to set ‘No restrictions on this transition’, which would allow anyone (with either of the global Document Manager roles) to make that state change.
In comparison, below we see that Everyone is denied the ability to change the state of a file from Work in Progress to Quick-Change. This is not an acceptable state change, so we effectively disable it for everyone.
When we consider using items, we shift all of the lifecycle control to the item record, and we set the items to control the files, based on the item states. In the example below, we have an Item Release Process lifecycle definition. We have a similar set of states, and can configure the state security as well as the transition security in the same way we configured the lifecycles for files. Note that in the item security, we have the option to set the security of files associated with the items, so that the item security is applied to the associated files. A locked item locks the files linked to it.
These lifecycle definitions can be applied to either the files directly or the items, but I strongly recommend not applying them at both levels, with one exception. If we set lifecycle security on an item, and we have an associated file, AND we set a lifecycle for the file, we have a loophole in our security. If I have the item state set to Released and the file state set to Released, the item and file are locked. If I leave the item as Released and change the state of the file to Work in Progress, the file is unlocked, even though the item is locked. The reverse is also true, that if I set the item to Work in Progress and the file to Released, the file will be unlocked and editable. If items are used by your company, you should apply lifecycles to the items and not to the associated files.
The exception I spoke of earlier is for the case where we have a file in the vault that will never be assigned an item. One example may be our Inventor project file. We would not itemize our project file, but we still want to control the users’ access to it, so that it is not modified unnecessarily. In this case, we should apply a file-based lifecycle to this file, so that we can limit when it is modified and by whom.
Through the lifecycle security, we control the file access and when those files can be modified or deleted. If we bring the global security back into the picture, a user with only the Document Consumer role cannot edit a file regardless of its the state. Editors can edit files as long as they are in a state that gives them permission to do so, and administrators cannot edit files in a locked state even though they globally have all permissions available at the global level.