Background to managing permissions on Asset Bank

One of the more sophisticated set of functions in Asset Bank is how we can use Groups and Folders to set the permissions of users. Put simply we can define the level of access that groups of users have with assets, by doing so we manage which assets a user can see and what they can do with them.

The following notes will help you understand the concepts involved, you can reach practical instructions by following the links at the bottom of this page.

"Fig 1 – Users sit in groups, assets sit in access levels"
Fig 1 – Users sit in groups, assets sit in folders

The following rules underpin the system of permissions in Asset Bank.

  • Every user is a member of at least one group.
  • Every asset is in at least one folder.

We can set the levels of permission between the groups and the folders. The permission levels set what members of that group can do with the assets in that folder (view it, download it and so on). You can see the full range of permissions here.

With these basic rules in place we can look at some simple examples to see how it works in practise.

"Fig 2 – The user as a member of Group 1"
Fig 2 – The user as a member of Group 1

In the above example our user is a member of Group 1. Group 1 permissions have been set so that they can see and download assets from Folder1, however they cannot see assets in Folder2. Therefore as a member of Group 1, our user can see and download the asset in Folder1, but cannot see or work with the asset in Folder2.

"Fig 3 – The user as a member of Group 2"
Fig 3 – The user as a member of Group 2

In the above example our user is a member of Group 2. Group 2 permissions have been set so that they can see and download assets from Folder1 and Folder2. Therefore as a member of Group 2, our user can see and download the asset in Folder1 and the asset in Folder2.

The hierarchy of groups

Two groups always exist in Asset Bank, the ‘*Public’ group and the ‘*Logged-in Users’ group.

When someone reaches Asset Bank without logging in they automatically become a member of the Public group. Once they have logged in they automatically become a member of the Logged-in Users group. You have the ability to create new groups and add users to it, however those users will always remain members of the Logged-in Group. This has a significant effect on user permissions.

"Fig 4 – The user as a member of Group 3"
Fig 4 – The user as a member of Group 3

  1. The user has not yet logged in and is therefore a member of the Public group.
  2. The user has logged in and is automatically a member of the Logged-in Users group, they gain all the permissions you have set for the Logged-in Users group. He also has inherited all the permissions from the Public group.
  3. You have set up a separate group (Group 3) with extra permissions. The user has been made a member of this group, therefore he has all the permission you have set for Group 3, he also has inherited all the permissions of the Logged-in user and Public groups.

This last point is very important, if a user is logged in, no matter what other groups they are a member of they will always retain the permissions of the Logged-in Users group. The user will always, no matter their setup, have the permissions of the public group.

For example, if a user in the Logged-in Users group can download ‘asset X’, then regardless of permissions set in Group 3, a member of Group 3 will also be able to download ‘asset X’. This is because users inherit the most open permissions of all the groups they are a member of.


Was this article helpful?

Yes No

Thanks for your feedback!