Valispace implements permissions on a project level, meaning that permissions for components, valis and matrices are always derived from the project they are located in. For instance, if vali_1 is part of ComponentX and ComponentX is part of TestProject and you have READ permission for TestProject then you will also have READ permission for vali_1 and ComponentX.
Permissions are cumulative, which means that higher ranking permissions always automatically include all lower ranking permissions. For example, read access is automatically included when you have write permission. The following three types are available (in cumulative order):
Read permission allows you to view a project and all its elements: components, valis and matrices. You can also use this data in other projects, for example in formulas of valis. However you cannot edit anything inside the project where you have read access.
In order to manipulate any elements inside a project you need to possess write permission for that project. With write permission you can edit and delete the project and all components, valis and matrices inside it. However, with a write permission you can not assign permissions for the project to other users.
Manage permission for a project gives you the ability to add or remove permissions for other users for this specific project. You automatically get manage permissions for a project when you create it. A superuser can also assign a manage permission to you or remove it.
Additionally to the project permissions there are a few special permissions that are assigned on a user level:
- Create projects
- Create/edit tags
- Create/edit types
All of the above are granted by default, but can be revoked by superusers.
In public projects every user is automatically granted WRITE permission. Projects are public by default and have to be made private if permission management is required.
Superusers by definition always have all available permissions. Superusers can also assign (and revoke) superuser rights to other users.
In the requirements module, you can add custom permissions on specification, group and requirement level. If no custom permission is set, the user will inherit the permissions from the higher level in the order: Workspace > Project > Specfication > Group > Requirement.
Add new permissions by clicking on
More options in the upper right corner and selecting
In the sidepanel that opens you can set the permissions for the object that you have currently navigated to. At the top of the sidepanel, you will see the name of the object that you are setting permissions for, in the example below it's the specification
Vehiclespecification. You can also see which object it inherits its permissions from if no custom permission is added.
To add permissions to a project, make sure that the project is not public. This is changed by unchecking the box
Everyone can read & write on the project level and adding permissions for each user or group there.
To add a custom permission, click on
Create Custom Permission in the sidepanel.
You will have two choices when creating a new custom permission, which are explained below:
Inherit permissions from
With this option you can set custom permissions on this object, which will also propagate to any children below this object. The default custom permission for each user will be inherited from the parent object. Also, when creating a new permission on the parent object, for example adding a new user to this project, for that user the permission for the current object will be inherited from the parent. This is also the case when a user's permission in the parent object changes, e.g. if a user has a custom read permission and has a write permission on the parent, if the parent permission changes to manage, the read permission will be overwritten with the new manage permission.
Some example use cases are:
- You want a user to have read access to a whole project, and custom write access to a specific specification and all requirements in that specification.
- You want a user to have write access to a whole project, but only read access to a specific specification and all requirements in that specification.
Start permissions from scratch
With this option all propagation of permissions from the parent level is stopped. There are by default no permissions created on the object, but you can add custom permissions for each user to this object. No permissions will be inherited from the parent, even when adding new users.
Some example use cases are:
- You want to restrict access to a specification and its requirements to allow only a few users to read and write. Other users will not see this specification.
- You don't want the permissions to be inherited from the parent if the permission of the parent changes.