Difference between revisions of "HowTo:Configure Users and User Rights"
| Line 5: | Line 5: | ||
=== Login === | === Login === | ||
| − | In {{UBIK}}, an account object is called [[Login]], with the system [[MetaClass]] ''LOGIN''. Theoretically, a user can have multiple such login credentials, but normally, you'd have one per user. If there are multiple logins for one user, you can create a custom meta class for the users and link the login objects to them via | + | In {{UBIK}}, an account object is called [[Login]], with the system [[MetaClass]] ''LOGIN''. Theoretically, a user can have multiple such login credentials, but normally, you'd have one per user. If there are multiple logins for one user, you can create a custom meta class for the users and link the login objects to them via the ''CONSUMER'' [[Reference]] property (see also how to [[HowTo:Relate_Objects]]). You can also create a derivation of the ''LOGIN'' system meta class to add further details for the instances. |
| + | A login object has the following important properties: | ||
| + | * ''LOGINNAME'': The account name | ||
| + | * ''DOMAINNAME'': The domain name | ||
| + | * ''SYSADMINRIGHTS'': Whether the user has administrator privileges in {{UBIK}} Studio | ||
| + | * ''USE_DOMAIN_CREDENTIALS'': Whether to use Active Directory for authentication | ||
| + | * ''PASSWORD'': The password | ||
| + | * ''CONSUMER'': A link to the person this login is associated with (useful if there are multiple accounts per person) | ||
| + | |||
| + | So, the steps to create a login are: | ||
| + | # Find the system meta class ''LOGIN'' and drag it into a new bulk editor. | ||
| + | # Create a new instance, filling in at least the ''LOGINNAME'', the ''DOMAINNAME'' and the ''PASSWORD''. | ||
| + | # Save the new instance. | ||
=== User groups === | === User groups === | ||
| Line 11: | Line 23: | ||
If you have just one group of users (i.e., all the users have the same rights or highly individual rights), it is not necessary to configure groups. | If you have just one group of users (i.e., all the users have the same rights or highly individual rights), it is not necessary to configure groups. | ||
| + | |||
| + | The steps to create and apply a group are: | ||
| + | # Find the system meta class ''USERGROUP'' and drag it into a new bulk editor. | ||
| + | # Create a new instance, filling in the name | ||
| + | # Save the new instance. | ||
| + | # Drag the new group into a relation browser. | ||
| + | # Find the login(s) you want to associate with the group and drag it onto the relation node for ''SYSREL_GROUP_LOGIN'' (relation between groups and logins). | ||
| + | # Save the changes. | ||
<!-- | <!-- | ||
== User rights == | == User rights == | ||
| − | There is no prepared feature for user- or group-specific rights in {{UBIK}}. However, you can customize user rights and their | + | There is no fully prepared feature for user- or group-specific rights in {{UBIK}}. However, you can customize user rights and their execution. |
| + | |||
=== Defining rights === | === Defining rights === | ||
| − | First, it will be necessary to define what rights there should be. | + | First, it will be necessary to define what rights there should be. In general, it should be possible to control whether a user is allowed to view ("read"), edit ("write"), create and delete data. Creation and deletion rights can be subsumed into the right to manipulate ("write") data. |
=== Configuring rights === | === Configuring rights === | ||
| − | + | So we have the basic definitions for reading and writing. Now we have to apply them to use-cases, respectively, objects and users (or better, groups). E.g., if it should be possible to control the rights for editing an object's properties, one could relate the respective user group to the object and set the right on the relation data object. Then, the group is related to the target object, with the respective right as a property of their relation connection. | |
| + | === Evaluating rights === | ||
| + | Now that we have defined and configured rights, we have to evaluate them. This can happen in many ways, | ||
--> | --> | ||
| − | |||
<!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS --> | <!-- DO NOT REMOVE THIS -->{{Template:HowTo/Begin}}<!-- DO NOT REMOVE THIS --> | ||
Revision as of 13:14, 16 December 2019
In many projects, it is important to distinguish the active user, mainly for the mobile client. Mostly, it is required to just restrict access to certain users. Often, there are also different groups of users that should have different rights to view, edit, create or delete objects. In some cases, the content provided to the mobile client should depend on the active user. This How-To explains how to configure users and how to customize a UBIK® application depending on the active user.
Managing user accounts
The first step in any case is to create and organize accounts for users. In some case, users have to be imported from an external system, which is best done using Proxies (see also how to Configure Proxies). However, accounts can also be created manually or programmatically. In any case, the following information is relevant.
Login
In UBIK®, an account object is called Login, with the system MetaClass LOGIN. Theoretically, a user can have multiple such login credentials, but normally, you'd have one per user. If there are multiple logins for one user, you can create a custom meta class for the users and link the login objects to them via the CONSUMER Reference property (see also how to Relate Objects). You can also create a derivation of the LOGIN system meta class to add further details for the instances. A login object has the following important properties:
- LOGINNAME: The account name
- DOMAINNAME: The domain name
- SYSADMINRIGHTS: Whether the user has administrator privileges in UBIK® Studio
- USE_DOMAIN_CREDENTIALS: Whether to use Active Directory for authentication
- PASSWORD: The password
- CONSUMER: A link to the person this login is associated with (useful if there are multiple accounts per person)
So, the steps to create a login are:
- Find the system meta class LOGIN and drag it into a new bulk editor.
- Create a new instance, filling in at least the LOGINNAME, the DOMAINNAME and the PASSWORD.
- Save the new instance.
User groups
Login accounts are best managed in groups corresponding to roles, e.g., "Administrator" or "Engineer". This is important if you don't want to distinguish by account individually, but more generally by their role. This allows you to add new logins (to existing groups) without having to adapt your customizing. There is a system meta class USERGROUP that can be used for this. Similar to the way you would link multiple logins to a user, you can also relate multiple users to one or many groups (there is a system relation for that, SYSREL_GROUP_LOGIN).
If you have just one group of users (i.e., all the users have the same rights or highly individual rights), it is not necessary to configure groups.
The steps to create and apply a group are:
- Find the system meta class USERGROUP and drag it into a new bulk editor.
- Create a new instance, filling in the name
- Save the new instance.
- Drag the new group into a relation browser.
- Find the login(s) you want to associate with the group and drag it onto the relation node for SYSREL_GROUP_LOGIN (relation between groups and logins).
- Save the changes.
