Users
See also: Guest users
The Users menu item can be found in the Main menu via the 'Administration/Accounts' menu node, provided sufficient permissions are available.
By default (see Custom overviews), an overview for the 'User' (User) entity type, which is also referred to as a 'User account', is opened.
View name: de.lobster.scm.base.security.user::User|listDetailsWindow
Menu node name: admin/accounts/userOverview
Access to Users is controlled by the permissions for the 'Administration/Accounts/Users' (administration/accounts/user) node.
Menu items for Users only appear if the permission for 'Show' (show) is available in Users.
Access to Users is generally subject to owner restrictions for the Company of session.
Permissions for the Role of session are therefore only effective for companies in which the Company of session is the owner or recipient of corresponding Company authorizations.
Importance of user accounts for access control
Users typically form the basis for logging in to a Lobster Data Platform session (see also User login).
Each user account must be linked to at least one company (see Companies/Clients) and at least one role (see Roles).
Users whose account is linked to multiple Companies/Clients and/or Roles must make a selection for the Company of session and/or the Role of session when logging in to a session.
The Role of session determines the categorical availability of permissions (see Roles).
The Company of session affects the application of permissions to specific entities, provided that owner restrictions must be taken into account for these.
Access control via permissions and owner restrictions is never based directly on Users. The 'range of action' for Users results primarily from their access to Roles and Companies/Clients when logging in
Only Companies/Clients can be considered as ‘owners’ of entities. Accordingly, only Company authorizations and no personal authorisations can be granted for Users.
However, entities refer to Users (or Guest users) with special importance regarding the entity via the automatically filled 'Creator' (creatorId) and 'Last modifier' (lastModifierId) fields. These references are not relevant for accessing the entity without explicit consideration in configurations.
If required, personal restrictions can be configured for Users, for example by User rule (e.g. in Association criteria or a case differentiation by If then else) or in the context of Restrictions (e.g. for Custom overviews or Combobox elements) that relate to Users.
►IMPORTANT◄ There are dedicated value resolvers that can be used to 'safely' handle Company value value references or a Role in configurations with a view to a Meta exchange. This is not intended for Users (and Guest users). Configurations that explicitly and directly refer to an ID (id) of an individual user account defined as a fixed value are therefore potentially a problem.
The interactive administration for Users is based on a combined view (listDetailsWindow) by default, which can be opened via the Users menu item in the Main menu.
The following screenshot shows the default ribbon (for a role with all relevant permissions), including the default input form with the details of the user selected in the list area (at the bottom).
Special features in the ribbon
In addition to the generic ribbon buttons (New, Delete, etc.), the main category ('Common') visible in the screenshot also contains a specific ribbon button for Companies/Clients:
Sub category |
Ribbon Button |
Description |
Logins |
|
The Show ribbon button is linked to the ‘Show login history’ permission (administration/accounts/user/showLoginLog). It opens a modal full-screen window (see Anmeldungsverlauf) within the current view that lists the login history of a selected user in the list area. |
Contents of the default input form
The data input form offered by default for Users only shows a selection of the total available content of the data structure for Users via Form elements.
'Users’ tab
Object |
Field |
Data path |
Example values |
Contents |
'User' |
Active |
active |
$true (Boolean) |
The Active checkbox must be ticked so that a user account can be used for a User login. |
Username |
username |
'don.duck@doma.in' |
A system-wide unique character string (case-sensitive) must be entered as the Username. ►NOTE◄ The uniqueness of the Username is only verified when saving. Saving is cancelled with an error message if the specified user name has already been assigned. As each user account can be identified as an entity via a unique ‘ID’ (id), the Username can be changed again for users that have already been created. However, this is only recommended to a limited degree, as the Username can also be used as a reference in the context of Orchestration integration (e.g. via Integration login or Create Login Request (Integration function)). Such references may be orphaned after being renamed. |
|
Password Password confirmation |
(passwordHash) |
'69f50cde6DD6' See also: Change password |
When creating a user, a Password must be entered and repeated without errors in the Password confirmation field.
|
|
Password expiry date
|
passwordExpiryDate |
22.05.2025 22:00(UTC)(DateTime) |
A Password expiry date can optionally be specified to trigger a prompt to change the password if the expiry date has already been exceeded when attempting to log in (with the previously valid password). |
|
►IMPORTANT◄ If a new password is entered in this dialogue and repeated correctly, this triggers the ‘Change’ event (see Common action event) for the user account. Event handling, which reacts to the ‘Change’ event for Users (see Check type), can evaluate two Boolean variables in this case:
The Password expiry date for the user is then already deleted. If a Password expiry date should also apply to the new password, this must be determined explicitly and assigned to the passwordExpiryDate field. With the Relative date with time resolver, this is possible either based on the current system time or, if applicable, relative to the previous expiry date, which can be read in the context of the ‘Change’ event via the Original entity resolver. |
||||
Locale |
locale |
'English' (en) |
Simple selection that links a specific Sprache to the company. |
|
Max. concurrent sessions |
maxConcurrentSessions |
1 |
This setting determines how many Lobster Data Platform sessions a user may use simultaneously. This restriction is checked at each login attempt. If a user exceeds the personal limit with an additional session, the new session will only be activated if the user agrees to log out of an existing session:
|
|
Companies |
companies |
'SL UK', 'SL Germany', |
Multiple selection of Companies/Clients from which the user can select the Company of session when logging in. If precisely one company is selected here, the company selection at login is omitted. |
|
►NOTE◄ The label ‘Hidden company account’ appears for companies that are already assigned and can therefore be removed in the context of the current session but cannot be selected again afterwards. ►IMPORTANT◄ A user account that refers to a 'Hidden company account' can be changed but not created. This is particularly relevant when copying an existing user account. If necessary, all hidden companies must be removed so that the copied user account can be saved. To access Companies/Clients for a Company selection for Users, the following scenarios must be defined by default:
In custom Input forms for Users, access in these two cases can be restricted by specific search restrictions for the Combobox element. |
||||
Roles |
roles |
'Guest', 'Admin (accounts)', |
Multiple selection for Roles from which the user can select the Role of session when logging in. If precisely one role is selected here, the role selection at login is omitted. |
|
►NOTE◄ The ‘Hidden role’ label appears for roles that are already assigned and can therefore be removed in the context of the current session but cannot be selected again afterwards. This applies to all Roles that cannot be accessed with the Role of session. ►IMPORTANT◄ A user account that relates to a ‘Hidden role’ can be changed but not created. This is particularly relevant when copying an existing user account. If necessary, all hidden roles must be removed so that the copied user account can be saved. |
||||
'Addresses' |
Salutation |
address.salutation |
'Mr' (MR) |
Single selection for the Anrede in the user address. |
Name |
address.name1 |
'Don' |
Free text that is used together with other fields for labelling. |
|
Name 2 |
address.name2 |
'Duck' |
Free text that is used together with other fields for labelling. |
|
Street |
address.street1 |
'Entenwerder Stieg' |
Free text for the street in the postal address. |
|
Street no. |
address.streetNo |
'66' |
Free text for house number(s) in the postal address. |
|
Account-No. |
address.accNumber |
'1901' |
Free text that can be used, for example, to specify an identifier for the user account in other systems. |
|
Country* |
address.countryCode |
'Germany' (DE) |
Single selection for the Land in the postal address. |
|
Zip code* |
address.zipcode |
'20359' |
Free text for the Zip code in the postal address. |
|
City* |
address.city |
'Hamburg' |
Free text for the name of the city in the postal address. |
*) Interactive changes to the Country, Zip code and City fields may trigger a lookup of data for Cities. When selecting an item in the automatically displayed dropdown, address fields that are not displayed in the default input form for Users may also be filled or overwritten with data stored for Cities.
'Communication infos' tab
The screenshot shows the format used in the default input form for Users to enter Communication infos.
Communication infos is saved as Plural attributes of the ‘Communication information’ (AddressCommunicationInfo) type for the user address.
A Communication type can be selected in the Type field. Several entries for the same Type can be assigned to an address.
In the Context field, a text key can be specified that characterises the intended use for the communication information in question. In the Context field, a text key can be specified that characterises the intended use for the relevant communication information.
The key information for the communication information (e.g. an e-mail address or a telephone number) should be entered in the Value field.
CAUTION
For Plural attributes, the restriction that there must be no duplicates between two instances of the attribute applies when saving. If the list of Communication infos contains at least two entries that are completely identical in Type, Context and Value, an error occurs when saving.
►NOTE◄ Communication information with the Type 'E-Mail' (EMAIL) is used frequently to store data for addressing in an automatic E-Mail. For Users, for example, the Mail address user resolver can be used to look up stored e-mail addresses for a specific Context directly without having to configure this read access to the attribute structure of the address in detail. However, simplified access via E-mail requires a Context to be stored in the attribute.
►NOTE◄ Even if Communication infos refers to a Communication type, these are not formally typed attributes but Plural attributes (see also Business objects and attributes). This must be taken into account when configuring accesses (see Attribute (Resolvers) or Projections).
'External user login infos' tab
The 'External user login infos' tab contains settings that enable user authentication via other systems (via LDAP, SSO).
In the screenshot, the character string that is also used as the ‘Username’ (username) in the specific example is explicitly specified as the Userterm for the SSO login via Microsoft Azure (see Provider alias).