Roles determine which parts of KLEKSI are visible to users and which actions they are allowed to perform. By using roles, you can precisely manage access to data, collections, and functionalities. When setting permissions, you can determine, per role, which read and write rights apply to collections, objects, procedures, elements, files, and other parts of the system.


Flexible user roles
KLEKSI offers a flexible roles and permissions model that allows you to create and manage roles yourself. This gives you full control over who can view, modify, or manage which information.

You can create roles for different types of users and then determine per part of the application:

• Whether a user is allowed to view the component.
• Whether a user is allowed to add or modify data.
• Whether a user is granted administrative rights.
• Or whether a user has no access at all.

Components for which a user does not have rights are not displayed. This keeps the interface clear and ensures that a user only sees the components relevant to his or her work.


Rights at different levels
Rollers can be applied to various components within KLEKSI.

Consider the following:

• Collections
• Object types
• Objects
• Procedures
• Elements
• Fields
• Selection lists
• DAM / File Manager
• Dashboard modules
• Frontend pages
• Media files

This allows you to determine in great detail which information is visible or editable.


Create custom roles
You can create an unlimited number of custom roles that align with your organization's working methods.


Create a new role
Go to Roles via the menu on the left.

1. Click on the + button.
2. Enter a name for the new role.
3. Set the desired permissions.
4. Click Save.

Examples of commonly used roles are:

• Volunteer
• Photographer
• Curator
• Visiting researcher
• Board member
• Project Employee
• External partner

Roles for dashboard users
Custom-created roles can be assigned to users of the dashboard.

This allows you to give users access to exactly those components needed for their work.

Example: Photographer
For example, a photographer only needs access to:

• DAM / File Manager
• Upload functionality
• Media files

Access to object management, settings, user management, and other components is then automatically disabled for this user role.

In this way, each user only gains access to the functionalities that are relevant to his or her work.


Roles for frontend visitors
In addition to dashboard users, you can also use roles for visitors to the frontend of your website.

This is particularly interesting when you use:

• The member portal
• Protected collections
• Researcher environments
• Extranet or collaboration portals

Examples of frontend roles are:

• Audience
• Member
• Donor
• Volunteer
• Researcher
• Board member
• Partner organization

Roles for Linked Open Data
KLEKSI also offers the option to use a separate role for data published via Linked Open Data (LOD).

With this, you can determine separately:

• Which data may be published publicly.
• Which data is only visible to members.
• Which data remains available exclusively within the dashboard.

This provides maximum control over the visibility of collection data.

Exclusive access for members
Using roles, you can make certain information available exclusively to specific user groups.

Examples are:

• Copyrighted material
• Non-public object data
• Research information
• Internal documentation
• High resolution images
• Exclusive collections

You can determine which roles have access per collection, element, file, or frontend component.

Users without the correct role will not see this information.


Combining roles with collections and elements
A powerful feature of KLEKSI is that roles can be combined with access rights to collections and elements.

This allows you to determine in great detail:

• Which collections are visible.
• Which objects are accessible.
• Which elements are visible.
• Which fields may be edited.
• Which files may be viewed.
• Which procedures are available.

This makes KLEKSI suitable for both small organizations and large institutions with complex rights structures.


Example
Suppose you have a collection containing both public and confidential data.

You can then, for example:

• Making the collection visible to all employees.
• Show financial data to administrators only.
• Making research information available to researchers.
• Make high-resolution images available to members.
• Publish only basic information via the website.

All within the same environment and based on roles.


Important
User roles form the basis of access management within KLEKSI. By carefully configuring roles, you ensure that each user has access only to the information and functionalities necessary for their work.

This not only increases data security but also makes the system clearer, more user-friendly, and easier to manage.