# Role Configuration

The Core Engine uses a role management, which allows creating multiple roles with different sets of rights. This way, users can be assigned to a role that corresponds to their rights in the 4ALLPORTAL.

For all role configurations in the GUI, go to admin snap-in General system configurations/User settings/Role configuration.

To create a new role, just click "Create role" in the toolbox and assign a name, description and optional, a parent role, if required. A relation parent role - child role will be considered in the role-based module settings for permission "role and down" (permission value details).
You also have the option to duplicate a role in case you only have small differences.

To configure a role's settings and permissions, select a role in the tree structure on the left. You can now manage a role's:

General settings: assign users and view profiles to this role and define a parent role, if required
Advanced settings: configure global feature permissions and presets like a role's theme, mega menu structure, global search parameters and super-admin status
Module settings: configure for all modules and their records a role's native permissions, feature permissions, and presets

Test Your Role Configuration

After you made your settings and permissions, you have the option to see the effects for a role from a user's point of view by using feature Impersonation.

# General/User

In tab General/User, you can

edit a role's general settings like name and description or link it to a parent role if required (panel Role information)
assign users to this role, impersonate as a user or create new users if required (panel User added to this role)
optionally assign a view profile which contains a role-specific object renderer set and layout set mapping (panel View profiles)

# View Profiles: Role-specific Object Renderers and Layouts

In this panel, you can optionally assign one or multiple view profiles to this role.

If you require specific, nonstandard object renderers or layouts for a role, you need to assign that role a view profile. View profiles map object renderer sets and/or layout sets created in advance.
For example, you can assign view profile "Photographer" with objecttype specific metadata renderers to your role "Photographer" only. This can apply to selected modules only, while all other modules remain default.

Please note: Assigning a view profile to a role is the last step for a role-specific display of a module. Before that, you need to:

consider what you actually need for what user role
create and store your custom object renderer (and layout) with the required changes from the default in your file system
create the required object renderer sets (and layout sets) in admin snap-in Module configuration/{module}/Object Renderer Set (and Module configuration/{module}/Layout Set)
compile the mapping for the required modules in admin snap-in General system configurations/User settings/View Profiles
assign the view profile to a role right here

Further Documentation

# Advanced Settings

In tab Advanced settings, you can configure global feature permissions and presets:

define a role's search parameters for the global search and if its users should have super-admin rights (panel Other settings)
set a role's default theme (panel Theming)
define the mega menu structure and startup module for a role (panel Menu structure)

In this panel, you can define the looks of a role's mega menu. For each visible module (i.e., all modules that are not set to "No" or "Hidden" in the role-based module settings), you can decide

to make it the startup module (click the "Home" icon next to a module)
to add it to a role's Favourites group which will appear as soon as there are favorites (click the "Drag" button and drag and drop it to the "Favorites" space)
to hide it from the mega menu (click the "Eye" icon next to a module)
the position within its space (click the "Drag" button drag and drop modules into the order you need)
to move it to another space, e.g. module "Files" from "DAM" to "Collaboration"

# Role-based Module Settings

In tab Role-based module settings, you can define for each installed module

a role's right to have module access in general
a role's right to see a module in the main menu (no entry deactivates this module for a role)
a role's native permissions to create, view, edit, assign, and delete this module's records (select values from the drop-down)
a role's feature permissions and presets (click a module's name for the feature permissions & presets pop-up) - see the Feature permissions and presets documentation

Above all module rows is the row for the global permissions. They hand down their value to all non-customized module values.

Attention!

The role-based module-settings make no difference between user modules and technical (background) modules required for a working system. When changing default permissions, please consider the consequences when taking or assigning rights.
For example, setting the Contact's module access to "no" or "only friendlyname" will prevent this role's users from adding a receiver to an eTicket or download package.

Please note: Some technical modules are hidden in the role configurations, so their permission values cannot be customized via the frontend (list of modules).

# Native Permissions

To configure a role's native permissions, go to admin snap-in General system configurations/User settings/Role configuration, tab Role-based module settings:

table with role permissions, highlighted: global permissions

# Hierarchy Model

The role management works hierarchically. It distinguishes global permissions that hand down their values down to all modules in the table like a cascade (first table row - highlighted above), and module-specific permissions that overwrite the global permissions for a module if set (all table rows below).

# Order of Permissions

Native permissions apply in a defined and descending order, where the system starts to check for custom, module-specific permission values:

If a specific module's native permission has a custom value, the values from table ce_role_accs in the database apply (show_in_role_config must be "true" or not set).

If not manually set, or set to "default", the system checks the following:
If the global module permission has a custom value, the values from table ce_role in the database apply (show_in_role_config must be "true" or not set).

If not manually set, or set to "default", the system does the following:
The module-specific native permissions from file modules/MODULE/setup.xml in the filesystem apply (How to change the module's default).

If set to "default", the system does the following:
The global native permission values from file global/defaults/native_permissions.xml in the filesystem apply.

Please note: If show_in_role_config is set to "false", both ce_role_accs and ce_role will not apply. With no values from the database, the XML values will apply.

If a permission value is shown black, a value was entered manually. This custom value applies (if set to "default": see order above).
If a permission value is shown greyed out, a predefined value applies (e.g. the global permission's or the product standard "Default").

# Permission Fallbacks

If even the global native permissions are set to "default", a system fallback applies. Its values are set to "no/no rights".
If for some reason a module's XML file cannot be read, the global permission's value apply.

Example

In the following example, the global permission for deleting records was manually set to "All". This value is handed down to all other modules. Users of this role can delete any records of all modules to which the global permission applies.
The module-specific value for "Collections" was manually set to "Own". The global permission is overwritten by "Own" and users of this role can only delete collection they have created themselves.

# What is the Default?

Our two standard roles "Administrator" and "User" come with predefined values. Some of them are set to "default". Also, when you create a completely new role, all global and module-specific native permissions are set to "default":

The "default" can be seen as the product standard or delivery status of a permission. Its values are stored in the system's XML files. This default always applies if a value is not changed manually to another value.

The actual XML values behind "default" are as follows:

# Global Permissions

"Default" =

Module name	Module access	Main menu entry	View	Delete	Edit	Assign	Create
all modules	no/none	no/none	no/none	no/none	no/none	no/none	no/none

Compare the XML values with the snap-in value names here.

# Core Engine Modules

Please note: If any other value than "default" is set for a permission, that other value applies.

"Default" =

Module name	Module access	Main menu entry	View	Delete	Edit	Assign	Create
API Key * api_key	superadmin: yes, else: no	no	public	public	public	public	yes
CE module permissions * ce_role_accs	superadmin: yes, else: no	no	public	public	public	public	yes
Emails mail	no	no	none	none	none	none	no
History recent_obj	yes	no	own	own	none	none	yes
Log events logevents	superadmin: yes, else: no	no	public	public	default (global fallback = public)	default (global fallback = public)	no
Login attempts * login_attempt	superadmin: yes, else: no	no	public	public	none	none	no
Request management request_mngt	yes	no	public	own	own	own	yes
Roles ce_role	yes	no	public	superadmin: public else: none	superadmin: public, else: none	superadmin: public, else: none	superadmin: yes, else: no
Saved filters * saved_search	yes	no	own	own	own	own	yes
Sessions * session	superadmin: yes, else: no	no	public	public	none	none	no
Update management * update_mngt	superadmin: yes, else: no	no	public	public	public	public	yes
User user (details see below)	yes	yes (shown)	default (global fallback = public)	default (global fallback = public)	default (global fallback = public)	default (global fallback = public)	yes
Versioning * version	yes	no	public	public	public	none	yes
Webhooks * webhook	superadmin: yes, else: no	no	public	public	public	public	yes
Webhook events * webhook_event	superadmin: yes, else: no	no	public	public	public	public	yes
Webhooks logevents * webhook_logevent	superadmin: yes, else: no	no	public	public	public	public	yes

* module does not show in role configuration

Please note: The minimum requirement for User module is to set "Module access" to "Yes". This gives access to the module's records including the user's profile and object image, or the possibility to assign users to records (Reference Find), e.g. to invite them to a collection.

Yes: access to this module's records, access to "user profile" menu, Reference Find, users' object images
No: no access to this module's records, no access to "user profile" menu, no Reference Find, no users' object image
Only friendlyname: only own username in header, access only to "friendly name" records, no Reference Find, no users' object image

# Permission Values

Please refer here for information about the storage of native and custom permissions in your filesystem/database.

# Explanation of Permission Values

This table explains all possible permissions that can be granted to users of the chosen role and module:

Permission (XML Value)	Snap-in Value (XML Value)	Description
Module access mod_access	Default (default)	permission according to default permissions
	Yes (yes)	Users get access to this module.
	Only friendlyname (friendlyname)	Users can only read this module's friendlyname, but has no further properties of this module, e.g. read, write ... permissions. (Make friendlyname settings in the Module Definition.)
	No (no)	Users get no access to this module.

Main menu entry menu_entry	Default (default)	permission according to default permissions
	Yes, shown (yes_default_shown)	Users can open this module via the mega menu because the module icon is displayed.
	Yes, hidden (yes_default_hidden)	Users can only open this module via URL parameter because the module icon is not displayed.
	No (no)	Users cannot open this module via the mega menu because the module icon is hidden.

View read	Default (default)	permission according to default permissions
	None (none)	Users cannot view this module's records.
	Own (own)	Users can view only the module's records they have created themselves.
	Role (role)	Users can view only the module's records they or another user of the same role have created.
	Role and down (role_down)	Users can view only the module's records they or another user of the same role or its child roles have created.
	All (public)	Users can view all records in this module unrestricted.

Delete delete	Default (default)	permission according to default permissions
	None (none)	Users cannot delete records in this module.
	Own (own)	Users can delete only the module's records they have created themselves.
	Role (role)	Users can delete only the module's records they or another user of the same role have created.
	Role and down (role_down)	Users can delete only the module's records they or another user of the same role or its child roles have created.
	All (public)	Users can delete all records in this module unrestricted.

Edit edit	Default (default)	permission according to default permissions
	None (none)	Users cannot edit this module's records.
	Own (own)	Users can edit only the module's records they have created themselves.
	Role (role)	Users can edit only the module's records they or another user of the same role have created.
	Role and down (role_down)	Users can edit only the module's records they or another user of the same role or its child roles have created.
	All (public)	Users can edit all records in this module unrestricted.

Assign assign	Default (default)	permission according to default permissions
	None (none)	Users cannot change field `owner_user` of this module's records.
	Own (own)	Users can change field `owner_user` of this module's records only if they have created them themselves.
	Role (role)	Users can change field `owner_user` of this module's records only if they or another user of the same role have created them themselves.
	Role and down (role_down)	Users can change field `owner_user` of this module's records only if they or another user of the same role or its child roles have created them themselves.
	All (public)	Users can change field `owner_user` of this module's records unrestricted.

Create create	Default (default)	permission according to default permissions
	Yes (yes)	Users can create records in this module.
	No (no)	Users cannot create records in this module.

← Permissions and Presets Security Configuration →