User & Group Management
Last updated
Last updated
A user is defined by their name, family name, email, password, and their group memberships. There can be only one user per email address. The permissions of a user are given by the groups he or she is part of. If the user is part of more than one group all permissions add up. Meaning that if Group 1 has read permissions for dashboards and read access to dashboard A and Group 2 has to have write permissions for dashboards and widgets and access write access to dashboard B and widget X. Then a user which is a member of both groups has to have write permissions for Group 1 and 2 and reading access for dashboard A as well as writing access to dashboard B and widget X.
In the overview of the User Management, you can see all users. If you click on a user you can change the groups he belongs to and see his permissions.
A user can have user management permissions only. Meaning the user can create or edit other users without having access to the Group Management area. The user can see other users only from the groups that the user is part of. Also, the user can create or edit other users only in/from these groups.
The general settings include name, description, owner, and the home dashboard. With the home dashboard, you can define which dashboard or release a user sees instead of the standard welcome page. You can also access it via the home button in the navigation bar. If the user is in multiple groups he can choose a home dashboard in the profile settings.
In the section about users, one can add and remove users from the group.
Setting a release as a home dashboard means, user will always land on an active version dashboard of selected release, when navigation to home page.
With things, you can define which data a user group has access to. If a thing is not added to the list user do not have access to the data related to this thing. This can be used if, for example, machines belong to different companies and the users of one company should not be allowed to see the data of the other company. This holds true for actual things as well as for things that are only used in virtual events (virtual things).
In this menu item, groups can be defined from which the released Things are additionally considered for this group. This supports the creation of hierarchies with low maintenance effort.
Example: At group A, the groups B and C are added as "things from other groups". For group A the Thing_1, for group B the Thing_2 and for group C the Thing_3 are added. The result is that group A has access to the data of all three Things. If a Thing is added to or removed from group B or C, this immediately affects the Things to which group A has access.
If a thing is from other group (inherited), in group things popup, it cannot be manually removed (tool tip will be shown). Only manually added things can be removed from the group.
Also, in case where a thing is manually added and then inherited from other group afterwards, it is considered as "from other group" and also cannot be removed.
In permissions, you can regulate the access and right to different parts of the application. The different parts are,
Automation, regulates permissions for automations.
Dashboard, regulates access to the dashboard edit and view mode. To be able to view the dashboard a user needs to have at least read permissions. For dashboards to properly work one does not need to have permissions for widgets or queries only if the user should be able to change these elements.
Dataset, regulates permissions for the dataset editor.
Dimension, regulates permissions for the machine master data menu (dimensions and instances). Even without these permissions, a user with access to the dataset editor can still use machine master data in a dataset.
Event Schema, a user with permissions for event schema is able to see/edit event schemas in the event schema management. Even without these permissions, a user with access to the dataset editor can use events in a dataset.
Script, regulates permissions for the script editor.
Subscription, regulates if a user has access to subscriptions or not
Tag, not used at the moment.
Thing, regulates permissions for the machine list (necessary to link instances of machine master data to machines) and the edge device management (for the edge device management "write" permissions are required).
User Management, regulates permissions for the user management.
User Group Management, regulates permissions for the user and group management.
Virtual Event, regulates if someone can create or view virtual event definitions.
Widget, regulates permissions for the widget editor.
A user with write permission to the user group management can give himself all the permissions and access to all things.
A user with 'Automation' permissions will also have 'Subscription' permissions
Write permissions grant full access to this part of the application. With the read permissions, one can view all elements but not change, copy or delete them.
You also have the possibility to inherit permissions from one group to another. To do that, simply click the Edit Groups button in the permissions section and select any groups you want to inherit permissions from in the upcoming modal window by clicking the Add button next to them.
After selecting groups to inherit from, you may notice that some permissions are now disabled. This is because the group you're currently editing now inherits these permissions.
If you don't want this group to inherit from another group anymore, simply click the Edit Groups button again and click the trashcan icon next to the group you want to stop inheriting permissions from.
Inheriting permissions currently is limited to one level of inheritance. This limit has two implications:
Let's image we have two Groups, Group A and Group B, where Group B inherits permission from Group A. A new Group C, can't inherit permission from Group B, because this would result in two levels of inheritance. This limit is visible in the UI by only showing you groups in the Edit Groups modal, that don't inherit permission from other groups.
Pretty similarly, if you have Group A and Group B, Group A can't inherit from another group, because this would also result in two levels of inheritance. This is visible in the UI by simply disabling the Edit Groups button when you are editing a group that is inheriting its permissions to other groups.
An element can be a dashboard, widget, dataset, script, automation, or a virtual event. Every element has an owner and can be shared with groups. A user has access to all elements they own or are shared with a group them is part of.
By default, the creator of an element is also the owner but the owner can be changed by someone with user group management write permissions.
A user with user management permissions is able to share any element they have read or write access to with any group. Users without this permission can only share elements they own or have write permissions to. But someone with read permissions can create a copy of an element which he will be the owner of and therefore will be allowed to share.
The second way to share an element is by group management. This option is obviously only available if you have permissions for the user management. Go to a group in the group management. There is one section about elements, where you can add and remove elements from a group.
Someone with write permissions can alter all aspects of the element and delete it. Someone with only read permission can not save changes and can not delete the element but is able to create a copy of it.
There are two ways to share an element. The first one is to go to the corresponding overview menu, look for the element you want to share and click (on the right side of your screen). Then select share and choose the group you want to share the element with.
