User Rights Management
PoolParty utilizes user roles to control permissions and user groups to control access.
This section contains a short guide on user rights management. PoolParty utilizes user roles to control permissions and user groups to control access.
Note
Only a PoolPartySuperAdmin can access the User Administration. They can create and manage users and user groups.
In PoolParty you can manage user access and permissions easily after you consider the following aspects:
User Roles: specific roles are linked with permissions on a granular level and are predefined.
User Groups: groups define which user may access specific projects, ontologies and custom schemes.
By combining the roles and groups, you can define user permissions in an individual access model. See the example below.
User roles in PoolParty are predefined sets of permissions. Permissions in PoolParty are based on actions and functions a user can execute in PoolParty. They are separated into two permission types:
Server Permissions are all rights a user needs to execute actions on the server level, such as creating or deleting projects or creating snapshots.
Project Permissions are all rights a user needs to execute actions on the project level, such as creating or deleting concepts, create corpora or link data.
Additionally, you can grant project-dependent user roles, which differ for a given user from his global permissions on that PoolParty instance.
Details on project-dependent user roles and settings find here: Define a Project Specific User Role for a User
Note
For more details on User Roles, refer to User Roles in PoolParty.
In PoolParty you can define user groups. They work as a container for projects, ontologies and custom schemes. Using groups, you can grant rights to users for the respective projects, ontologies and custom schemes by assigning the corresponding group to them.
The only default group predefined on any PoolParty instance is the group Public.
The Public group has to be assigned to projects, ontologies and custom schemes if you want to make data publicly available. This group cannot be deleted.
The following features are provided when assigning the Public group:
Project
Ontology
Linked Data Frontend
Custom Scheme
Linked Data Frontend
Note
For more details on User Groups, refer to User Groups in PoolParty.
For example, let's assume we have two projects, called 'All about Cocktails' and 'Wine & Cheese Recommender'. Additionally, an ontology and a custom scheme are available for the cocktails project.
Now we want to define one person (Admin) who has the right to manage these projects as well as the respective ontology and custom scheme.
We also need one person who should be able to manage the ontology (Ontologist); and two people who only work on one of the two projects (i.e. only have access to their project, CocktailsEditor, WineCheeseEditor).
We also need to have a read-only user able to access both projects (Viewer).
For this scenario we then require three user groups with respective access rights (CocktailsGroup, WineCheeseGroup, and CocktailsOntologyGroup).
The diagram below shows the different users along with their groups and roles as well as the projects and ontologies/schemes with the necessary groups.
 |
Tip
If you would like to learn more about this topic, please watch this PoolParty Academy Tutorial video:
When the video is not available, you can sign up to the PoolParty Academy.