Guest users
Besides regular users, Lobster Data Platform / Orchestration offers the possibility to create temporary 'guest users'. In contrast to regular users, guest users are identified by a generated Login-Token. instead of a user name. A guest user account may also restrict the number of logins and a period of validity. When one of these limitations are exceeded, the guest user account will not allow further logins.
Guest users are managed by an overview available via the Guest users menu item.
Guest users (overview)
The list area (1) displays all guest user accounts visible in the context of the session. Depending on further permissions, it may be possible to add new accounts (New, Copy) or edit or delete existing ones (based on selection in the list).
When creating a guest user, a Login token can be generated by clicking on the key symbol (2) button. The generated string is required for logging into the system with a guest account. It is also possible to enter a string directly instead of creating the key. The system checks if the entered or generated Login token is unique when Save is clicked and will not create or update accounts with a Login token already in use. Therefore, when an account is created as a copy, the copied login token needs to be replaced before saving.
A guest user account can be defined as Active (3) or inactive. Inactive guest users are denied access to the system and notified by a message when trying to login.
The Locale (4) combobox sets the locale for the guest user session. Changing the language preference is not possible within a guest user session.
A guest user account must be linked to exactly one Role (5) and one Company (6) by a dropdown selection, which automatically applies for each session, as they would for a regular Users with no alternatives to choose from.
Entering an E-Mail address (7) is required for a guest user account. The address is stored in an object property E-Mail (emailAddress) and can be referred to, e.g. for sending notifications automatically.
The number of times a guest user may log into Lobster Data Platform / Orchestration can be limited by Max logins (8). A value of 0 will be interpreted as 'no limitation' . The field Login count indicates the 'logins spent', i.e. how many times a guest user has already logged in. If a value other than 0 is entered into Max Logins (8), and if that number is less or equal to Login count, the guest user is denied access to the system. The limit can be edited as required for existing accounts.
The Max concurrent sessions (9) field limits the number of concurrent sessions the guest user is allowed to run. Input values are constrained to values > 0.
A Valid to (10) date can be defined to limit the use of a guest user account by a certain point in time.
The Custom data > edit (11) ribbon button opens a simple XML editor, which allows viewing and editing custom content for the guest user account. Typically, such content will be provided automatically, often by the mechanism that created the guest user account itself. A sample application involving Custom data is described in the section 'Configuration example' below.
Clicking the Login history > Show (12) button lists a record of all logins for the guest user. This history list includes ongoing sessions.
Login procedure for guest users
The login type can be selected by clicking the cog wheel symbol (1) in the top-right corner of the login screen. After selecting Guest login (2), the login token may be entered and the guest user be registered in the system.
►NOTE◄ In connection with the guest user login, URL Parameters offer interesting possibilities for influencing the behaviour when calling the system.
Configuration example
In the following example guest user accounts are used to grant limited reading access to specific shipments, based on individual restrictions for each guest user account defined by the following parameters:
On the one hand, shipments should only be listed if modified within a limited time horizon before the current time.
On the other hand, a text attribute 'Plant' of the shipment, which defines the relevance of a shipment for the guest user, should be matched against a specific filter criterion.
Further restrictions regarding the visibility result from the context of the company account predefined for the guest user account and definitions for ownership, involvement and Effective authorizations – without any dedicated configuration in the current context.
The relevant guest users are assigned a role that grants the following permissions only:
Business objects/Shipments/Read
Business objects/Shipments/Show details
Further, a special shipment overview is configured (see Custom overviews), with a condition processing the mentioned parameters per guest user account. These parameters will be stored as 'Custom data' in the guest user account and are defined in a portal, that is opened as a modal dialog from a guest user overview by clicking the ribbon button (command 'Portals > Open portal'), provided a single selection identifies the guest user to update:
When the portal is opened, data from the selected guest user account is automatically included if the form design includes a container pointing to 'loadedItem' as a data field. In our example, this container features the elements ID (data field: id), Login token (loginToken) and E-Mail (emailAddress).
Below, a filter for Plant (data field: PLANT_FILTER) can be defined by Combobox (with the key values A120, A121, A125, A127 and A12_ represented as options). The selected value is referred (as shown later) by the LIKE condition defined for the text attribute Plant (t_PLANT.value.text) in the custom overview.
To the right of the plant filter options, a date picker labelled modified as-of ... (data field: MINDATE) specifies the time horizon by setting an earliest date matched against the lastModified timestamp of a shipment by a 'Greater or equal' constraint for the custom overview.
Both filter criteria are elements of a container 'filters' (not visible in the screenshot), to facilitate handling of the combination in configurations (see below).
Clicking the Save restrictions button triggers a Dispatch custom action event (Form designer) 'Guest user – set data' (SET_GUEST_USER_DATA) behaviour to kick off the following event handler:
Since the Triggering events will exclusively be addressed from the portal, the only Validating rule included here is a sub-criterion checking the proper context for executing the actions (Company rule, Role rule).
All actions will be executed in the context of the guest user account selected. This account is resolved from the variable 'formData' (of the 'Client object' type) of the portal within the Execute with action. For this purpose the content of container 'loadedItem', representing the selection, is processed by an Input object (type safe) resolver returning the 'Guest user' object.
Finally, the value of the 'Custom data' (customData) object property of this account is set by a Set value action, which transfers the settings from the 'filters' container in the portal provided in the 'formData' variable.
The Save changes later action ensures that this change in the guest user object is saved although the object was only added via Execute with.
The result of an assignment of filter criteria by this method can be verified, e.g. by clicking the 'Custom data > edit' button in the guest user overview:
In the custom overview Shipment overview (Guest user) condition, the filter criteria are then included as follows:
The text attribute 'Plant' (t_PLANT.value.Text) is matched by LIKE against the choice for 'Plant' (PLANT_FILTER).
For this purpose, the User of session is identified and the corresponding guest user account resolved by Input object (type safe).
Guest user object property 'Custom data' (customData) provides the object (object) generated from portal data including fields (property) PLANT_FILTER (string) and MINDATE (DateTime).
As shown, another Object property resolver retrieves the value of PLANT_FILTER for matching.
The MINDATE property is accessed by the same method to match against the lastModified timestamp (below).
Use example results:
The following screenshot shows example results for a guest user with access to all plants of 'Group A-12' (filter criterion: [Plant] LIKE 'A12_') modified 06/01/2019 or later.
In contrast, another guest user will see the following result based on the permission for plant 'A120' only, but an extended time horizon starting from 01/01/2019: