User Rights Management
PoolParty utilizes user roles to control permissions and user groups to control access. Learn more here.
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: they provide permissions on a granular level and are predefined.
User Groups: they provide access for users to 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 you have two projects, called 'All about Cocktails' and 'Wine & Cheese Recommender'. And for the cocktails project, there is also an ontology and custom scheme available.
Now you want to have one person (Admin) that sets up those projects and the ontology and scheme.
One person that should be able to manage the ontology (Ontologist). And two people who work on the respective projects only having access to one of them (CocktailsEditor, WineCheeseEditor).
Also, there should be a read-only user able to access both projects (Viewer).
To facilitate this scenario we need three user groups to grant access (CocktailsGroup, WineCheeseGroup, CocktailsOntologyGroup).
The diagram below shows the different users with their groups and roles and 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.