User

Modified on Tue, 23 Jul at 2:36 PM

The User menu item combines the former "LDAP Groups" and "Users" menu items.

The menu item User in the user administration of clients is used to authorize logged-in users within the client or within the forms of the client. Specifically, the following goals are pursued:

give individual users or groups of users access to the client's administrative interface and control their permissions within clients.
Grant end users access to protected forms or parts of forms.

Therefore the list of users only represents the authorizations for users. A complete list of all users in the system can be viewed in the system settings.

Newly created clients always already contain an authorization for a user, namely that of the client administrator. See Client creation.

Contents

Adding users

To add a user to the client, click on the plus icon. After that, a selection with two options appears, because there are two ways to create an authorization for users in clients:

By sending an invitation by e-mail (exactly one user is authorized).
By defining user filters (several users can be authorized at once).

User configurations with client admin role can only be added by users with Edit admin role permission or by the SAdmin.

Inviting users via email

Inviting a user via their email address.

To invite a single user to the current client, click Invite user by e-mail.

Email

The email address of the user who is to be invited to the client. It is only necessary to specify the email address of the user. This can be a user who is already registered in the system or a completely new user. In both cases, the user will receive an email with an invitation link.

If user search is enabled for the system, suggestions are made based on the users that already exist in the system when the email address is entered. If LDAP or Microsoft Entra ID login services are enabled for the management interface, suggestions are also made based on LDAP servers and Entra ID login services, respectively.

The other fields such as role and user group are described in the Authorization configuration section.

By clicking on Invite, the authorization for the user is created in the client and an email with an invitation link is sent to the user. By default, the invitation links have a validity period of one day. After this time, the invitation link can no longer be used. A new link must be sent. The validity period of the invitation links can be configured in the application properties.

A correctly configured system email server is a prerequisite for sending the invitation emails.

A user invited by email who has not yet accepted the invitation. Even if the user already exists in the system, no information about him/her will be revealed until they have accepted the invitation.

After the invitation has been sent to the user, the user configuration is in the "waiting" state until the user responds to the invitation.

Nach dem die Einladung an den Benutzer versendet wurde, befindet sich die Benutzerkonfiguration im "wartenden" Zustand, bis der Benutzer auf die Einladung reagiert.

Copy invitation link

The invitation link can be copied via the clipboard icon.

Send new invitation

A new invitation can be sent via the paper airplane icon, the invitation link of the previous invitations will become invalid.

Invitation from the user's point of view

When a user is invited to a client, the user must follow the link in the invitation email. After clicking on the invitation link, the user will be prompted to log in or register.

Invitation of an existing user

The login prompt for invitations with email addresses known to the system.

If the email address used for the invitation is already known to the system and assigned to a user, the user is asked to log in with their formcyle profile.

Invitation of a new user

The login or registration process for invitations with email addresses unknown to the system.

If the email address is not yet known to the system at the time of the invitation and therefore could not be assigned to a user, the user will be prompted to register with an email address. This does not have to be the email address with which the user was invited. Afterwards the user will be asked to enter their name and a password to create a new profile.

If the user already has another formcycle profile under a different email address, they can also log in with this profile to accept the invitation.

If external login services are configured for the management interface and the user has an account with one of these login services, the user can also log in or register with this account.

Accept / decline invitation

After successful login or registration, the user can accept the invitation and then receives the assigned authorization within the client. If the user declines the invitation, the user authorization is removed from the client.

Profile pictures and full names of users are visible to others in the client only after the invitation has been accepted by the user. Until that time, only the email used for the invitation is visible.

Whether invitations have to be explicitly accepted by users can be configured by system administrators in the system settings.

After the user accepts the invitation, it will be displayed with full name and, if available, profile picture.

Creating user filters

Creating a user filter to assign authorization to a group of people within the client.

To create a user filter, click on Create user filter.

Name

The name to give to this user filter.

Description

An optional description for the user filter.

The login service for which the fitler is to be created. Only for users who log in via the selected login service does this user filter and thus the configured authorization within the client take effect. The login service determines how the filter is to be configured. See Filter configuration.

Filter type

Specifies the type of the filter. The filter type determines how it is to be configured. See Filter configuration. The filter type is selectable only for login services of type LDAP and Kerberos.

Filter configuration

There are three types of user filters by default:

LDAP filter

LDAP filters can be configured only for LDAP and Kerberos type login services. For LDAP filters, a user search request is made to the LDAP server based on the configured filter. The following information is required for the configuration of:

BaseDN: Represents the root to search for user objects on the LDAP server.
Filter-Abfrage: an optional filter query to apply further restrictions within the set of user objects of the LDAP server (Tutorial)

The Group search button lists all groups available on the LDAP server within the given BaseDN. This list can be further filtered via the search field and with a click on an entry the filter query is preset.

Configuration of an LDAP user filter by using the group search.

Only users, the LDAP filter applies to, are assigned to this user configuration and thus to the authorization within the client.

LDAP filters behave the same way as LDAP groups from previous formcycle versions.

Profile condition

This filter type is available for all login services including plugin login services. Here, multiple conditions can be defined on properties of the user profile and how these conditions should be logically linked. The properties of the logged in user profile are available as a JSON structure. To check properties, the JSON path to them is selected (see Conditions below).

Connection: the connection specifies how the configured individual conditions are to be logically linked to each other. Three options are available:
- All must apply (AND): All configured conditions must apply in order for the logged-in user to be assigned this user configuration and thus authorization within the client.
- One or more must apply (OR): At least one of the configured conditions must apply in order for the logged-in user to be assigned this user configuration and thus authorization within the client.
- User-defined connection: For complicated cases, this option allows one to enter any logical links of the configured conditions. By default, the conditions are evaluated from left to right. By using brackets, the order of evaluation can also be influenced. The conditions to be used must be inserted as follows:
  - cN: A condition, for example c1 or c3. The names of the conditions are always in the heading of the condition. For a better overview, the names of the conditions can also be changed by clicking on them.
  - not: negation, which must precede the value to be negated. For example:
    - c1 and not c2
    - c1 or not (c2 and c3)
  - and: AND operation, which is true if both concatenated values are true. For example:
    - c1 and c2
    - c1 and not c2 and c3
  - or: OR operation, which is true if one of the two concatenated values is true. For example:
    - c1 or c2
    - c1 or c2 or not c3
  - false, true: These two constants represent the logical values false and true.
  - xor, nand, nor, implies, impliedby, equiv, unequiv: Represents, in this order, the logical operators Contravalence, Alternative Negation, Common Negation, Material Implication, Opposite Implication, Material Equivalence, and Nonequivalence.
Conditions: Any number of conditions can be specified. A condition can check exactly one profile property.
- JSON path to the property
  The JSON path selects a property of the profile and thus a part of the JSON object that represents the profile of the logged in user. A condition can then be checked on this property/part of the JSON object. The selected property can take different forms, namely all valid JSON data types:
  - String: A sequence of characters that represents a testable property.
  - Number: A number that represents a testable property.
  - Object (JSON object): represents a complex property of the profile. As a rule, no condition can be meaningfully checked for JSON objects. So the JSON path should be extended to select a testable sub-property of the object.
  - Array: a set of additional elements / properties. The elements of the array can be any of the valid JSON data types. As a rule, however, testing only makes sense with arrays whose elements are of type String, Number or Boolean. If this is not the case, then the JSON path should be refined to select a testable attribute. For arrays, usually only the conditions Empty, Not empty, Contains and Does not contain can be used meaningfully.
  - Boolean: can have the value true or false and represents a testable property.
- Condition: Condition to test. The following options are available for selection:
  - empty
  - not empty
  - equal
  - not equal
  - contains
  - does not contain
  - greater than
  - greater than or equal to
  - less than
  - less than or equal to
  - starts with
  - does not start with
  - ends with
  - does not end with
  - matches regexp
  - does not match regexp
- Value to compare ageainst: The value of the selected condition used for the check. Visible if Empty or Not Empty is not selected as the condition.

Please note that certain conditions must be used for certain constellations. For example, when comparing with an array, the ‘Contains’ condition must be used instead of the ‘Equal’ condition, even if there is only one element in the array.

Configuration of a user filter via two AND connected profile conditions. In this example, all users are assigned to this user configuration who are part of the group "Clerk" (memberOf) and in the organistaion "Demo AG " (organisation).

Only users whose profiles match the individual conditions ind the selected link are assigned to this user configuration and thus to the authorization within the client.

Examples of filter configurations

The following examples are intended to check whether you belong to a group with a specific name. The check is carried out using JSON path notation.

Example data from a Microsoft Entra ID login:

Example data from a user login with Microsoft Entra ID

Filter configuration for checking group membership (memberOf) in the group with name (displayName) "internal-users".

Example data from a Microsoft Active Directory login:

Example data from a user login to a Microsoft Active Directory

Filter configuration for checking group membership (memberOf) to the group named "Internal-Users". It is important to ensure that the complete path to the AD group is specified as the comparison value.

Microsoft Entra ID filter

Microsoft Entra ID filters can only be configured by Microsoft Entra ID login services. The Entra ID filter is very similar to profile conditions and can also be configured in the same way as profile conditions by specifying conditions on JSON paths. However, in addition, it is possible to define conditions on known properties of Entra ID profiles:

User groups: This profile property represents the list of user groups of which the user is a member. When this property is selected, suggestions of existing user groups appear in the comparison value field. This profile property is available only if the selected Microsoft Entra ID login service has the "Query full group information" option enabled. In addition, the Group.Read.All application permission must be granted in order for formcycle to make suggestions based on the Entra ID tenant's user groups.

Grant the application permission Group.Read.All via Entra ID Admin Center to allow formcycle to make suggestions based on Entra ID tenant user groups.

Manager: This profile property represents the manager of the user. When this property is selected, suggestions of existing users appear in the comparison value field. This profile property is available only if the selected Microsoft Entra ID login service has the "Query manager" option enabled. Also, the User.Read.All application permission must be granted for formcycle to make suggestions based on Entra ID tenant users.

Granting the User.Read.All application permission via the Entra ID Admin Center to allow formcycle to make manager suggestions based on Entra ID tenant users.

Configuration of an Entra ID user filter using two AND connected profile conditions. In this example, all users are assigned to this user configuration that are part of the formcycle users and Departement C user group.

Plugin filter

It is also possible that plugin login services provide additional user filter extensions.

Testing user configurations

User configurations and their set conditions (profile conditions, Entra ID) or filters (LDAP filters) can be tested with a user login by clicking the "Test user configuration" button. After clicking the button, a prompt for entering a user login appears. After successful login, the profile information of the user is displayed in JSON form and above it, whether the authorization of this user configuration was successful or not, i.e. whether the selected conditions / filters are effective for the user or not.

Test result of a user configuration with successful authorization result.

Authorization configuration

User configuration overview

Roles

The roles assigned to the user within the client. Roles determine the access to the client's administration interface and which permissions the user has within the client.

If no roles are assigned, users are not granted access to the client's administration interface. This may be explicitly desired if end users are to be granted access to protected forms, for example, by assigning them only to user groups and not roles.

The roles of client administrators can be changed only if the user has the corresponding permission to edit the administrators and if there is at least one other client administrator.

Users can not edit their own roles.

For user filters, role selection is not available if the selected login service has not been configured for the management interface.

User groups

The user groups to which the user should belong. The user groups determine which inboxes users have access to, provided the users have access to the inbox via a corresponding role. In addition, user groups can be assigned to grant end users access to protected forms or to configure properties of form elements such as their visibility or editability depending on the user.

Accessible Inboxes

Represents the inboxes that can be accessed. Which inboes can be accessed depends on the user groups.

Access until

An end date can be set for users who should only have temporary access to the client. If users log on after the set date, the authorization by the user configuration will no longer be effective and thus, for example, access to the administration interface of the client will be denied.

Limited / temporary access cannot be configured for client administrators.

Editing / deleting users

In general, users can be deleted and edited once they have been created. Depending on the type (invited users or user filters), environment (other users) and the permissions of the acting user, however, there are restrictions on deleting / editing.

Invited users

Invited users with client admin role:

Editing: Can only be edited by the SAdmin or users with the role permissionEdit administrators if at least one other client admin exists as an invited user.
Deleting: Can only be deleted by the SAdmin or users with the role permission Edit administrators if at least one other client admin exists as an invited user.

Invited users without client admin role:

Editing: Can always be edited.
Deleting: Can always be deleted.

Yourself (The configuration of an invited user, which is the acting user itself):

Only the user groups can be edited.
The user cannot be deleted.

User filters

User filters with client admin role:

Editing: Can be edited only by the SAdmin or users with the role permissionEdit administrators.
Deleting: Can be deleted only by the SAdmin or users with the role permission Edit administrators.

User filters without client admin role:

Editing: Can always be edited.
Deleting: Can always be deleted.