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)

images/download/attachments/62849877/image2019-6-14_10-18-52-version-1-modificationdate-1603449416911-api-v2.png

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.

Login procedure for guest users

images/download/attachments/62849877/image2018-9-25_15-54-19-version-1-modificationdate-1603449417021-api-v2.png images/download/attachments/62849877/image2018-9-25_16-0-40-version-1-modificationdate-1603449417029-api-v2.png

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:

images/download/attachments/62849877/image2019-6-14_13-10-41-version-1-modificationdate-1603449416907-api-v2.png

  • 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:

images/download/attachments/62849877/image2019-6-14_13-31-16-version-1-modificationdate-1603449416898-api-v2.png

  • 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:

images/download/attachments/62849877/image2019-6-14_13-44-38-version-1-modificationdate-1603449416894-api-v2.png

In the custom overview Shipment overview (Guest user) condition, the filter criteria are then included as follows:

images/download/attachments/62849877/image2019-6-14_13-49-5-version-1-modificationdate-1603449416885-api-v2.png

  • 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.

images/download/attachments/62849877/image2019-6-14_14-5-51-version-1-modificationdate-1603449416867-api-v2.png

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:

images/download/attachments/62849877/image2019-6-14_14-7-16-version-1-modificationdate-1603449416859-api-v2.png