Rights Guide
This guide is designed to familiarize you with the object rights system. It will help you make efficient and secure decisions when assigning rights to participants in your project. In just 10 minutes, you will become an expert on the subject.
Object Hierarchy and General Rule
In AssetCurrent you will be working with the following objects: Projects, Collections, Assets, Artifacts, and Comments. The full schema is shown in the image below.
The general rule is as follows: If you are the creator of a particular object, you always have full rights to the object itself and its child objects as long as you have access to the parent object.
For example, if you are the creator of an asset, you have full rights to the asset itself and all its artifacts as long as you have access to the collection where the asset is located. Similarly, if you create a collection, you have full rights to it and all assets inside, as long as you have access to the project where the collection resides. Naturally, as the project creator, you always have full rights to everything within it.
This general rule allows object creators to easily revert actions made by mistake without requiring assistance from participants with higher privileges.
However, you should be cautious when assigning creator permissions, especially for high-level objects. Such powerful participants can delete the entire object with all child objects which may include work done by other contributors.
AssetCurrent provides some protection against accidental deletions, but it cannot prevent intentional actions. Ensure that you grant "Create" permissions only to participants with a high level of ownership and responsibility.
Rights Description
In AssetCurrent you can set granular rights at the project and collection levels. However, these rights apply only to objects that participants did not create. As per the general rule, participants always have full rights over the objects they create.
We will go through both project and collection rights, followed by best practices for assigning rights in an efficient and secure manner. Let’s start with collection rights.
Collection Rights
- Read: Allows participants to view all assets within a collection. They can also read comments and view/download artifacts in collection assets. However, they cannot reply to comments or edit artifacts.
- Add asset: Allows participants to create new assets within the collection. As per the general rule, the creator will have full permissions over the asset and all its content.
- Edit asset: Allows participants to edit assets in the collection. They can change asset names, statuses, and assignees, as well as add comments and attach artifacts. However, they can only delete artifacts or comments they created themselves. This permission also enables the management of public links.
- Delete asset: Allows participants to delete any assets within the collection. They can also delete any comment or artifact within any asset in the collection. This is a powerful permission and should only be granted to collection administrators.
Project Rights
- Read: Allows participants to see the project in their project list and view the project name. This right alone does not grant access to collections within the project; separate "Read" rights must be assigned for each collection you want to share.
- Edit project: Allows participants to edit the project name.
- Delete project: Allows to delete the project. This should be given only if you intend to surrender project ownership entirely. It is unlikely you will grant this right without assigning all other available rights.
- Add collection: Allows participants to create new collections within the project. The collection creator will have full permissions over the collection. This right should be granted only to high-level project administrators.
- Delete collection: Allows participants to change collection names, icons, or delete collections within the project, but only if they have "Read" access to those collections. This right should be granted only to high-level project administrators.
- Add user: Allows participants to add new members to the project. However, they cannot grant or change rights they do not possess themselves. This permission is relatively safe if given to someone with limited other permissions. The main concern is confidentiality, as the participant can grant "Read" access to anyone. Typically, this right can be assigned to project managers.
Scenarios
Granting only "Read" permission for a collection is useful for presenting results to final consumers, external reviewers, or participants who should not be involved in the creative process. Be aware that they can still see all comments and attachments in the entire collection. It may be something that you want or may be not. More on that in the later sections.
For regular creative workers, who will actually craft the assets, consider granting "Add asset" or "Edit asset" or both.
A safer approach is granting only "Edit Asset" for a collection where assets are created by collection administrator. It's highly likely that several people will work on multiple assets. The approach ensures that no assets will be added or deleted.
Granting only "Add asset" is more flexible approach, it allows creative workers to organize assets independently which is useful when a small number of contributors are working on complex compound assets like videos or full articles.
For lead contributors consider adding both "Add asset" and "Edit asset" rights. While doing the job themselves, they can monitor and assist others in the collection.
Granting just the "Read" rights to collections plus "Add User" right at the project level is ideal for project managers. This allows them to onboard new participants and oversee progress without giving them excessive control.
Powerful permissions like "Add Collection", "Delete Collection", "Delete Asset" should only be granted to high-level administrators responsible for the final outcome of the entire project.
Risk Management and Object Zoning
In some cases, you may want to restrict contributors from seeing other assets and progress on them. For example, if a musician is working on a song and should not see other songs in the project, you can create a separate collection or even separate project for such contributor. Object zoning is a common strategy for onboarding external contributors with limited access.
Another scenario is preventing participants from deleting objects they created and all its child objects after they finished the work. Since the creators always have full rights for objects they created, you can revoke their "Read" permission from higher-level objects (collections or projects) to prevent destructive actions. For temporary and transient workers, you may always want to create separate collections or projects.
Object Tagging
For the better management for your zoned objects you can prefix collection and project names with tags such as _outsource_, _restricted_, _temp_.
You can also assign tags based on the object's purpose. The final names may look like _sandbox_Grand Festival Banners, _experimental_Engine Models, _legal_Registration Documents.
Of course the particular tag format is always up to you.
Other Useful Resources
