It's important for administrators to understand how users are granted permissions throughout Asset Bank, as there are a number of overlapping features that control this.

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 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 practice.

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 Folder 1, however they cannot see assets in Folder 2. Therefore as a member of Group 1, our user can see and download the asset in Folder 1, but cannot see or work with the asset in Folder 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 Folder 1 and Folder 2. Therefore as a member of Group 2, our user can see and download the asset in Folder 1 and the asset in Folder 2.

Group hierarchy and inheritance

Two groups always exist in Asset Bank, the ‘*Public’ group and the ‘*Logged-in Users’ group - it is possible they have been renamed, but they will always exist in the system in terms of functionality.

When someone reaches Asset Bank without logging in they have all of the permissions granted to the Public group. Once they have logged in they have, additionally, all of the permissions 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

1. This public user has not logged in, and therefore only has the permissions of the Public group.
2. The used is logged in and therefore has the additional permissions granted to the Logged-in Users group. They also has inherited all the permissions from the Public group.
3. An additional group has been created ("Group 3"), and this third user has been manually added to this group. This means they will have additional permissions based on the settings for Group 3. They have also inherited all the permissions of both 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 both this Public and Logged-in Users groups.