Add users and assign roles

This section covers adding and updating Users and providing them with the correct Roles.

In important note on Users in Appfarm, is that one User (with an unique email as login) may exist only once inside a solution. The build-in Users database is shared across environments. Therefore, providing a User with correct Roles, and restricting access to various environments by Roles is important.

Users and Roles is also covered by a series of videos in the User handling and permissions module of the Appcademy Fundamentals learning path.

How Appfarm evaluates a User in the client (Apps)

When logging into the client (https://YOUR-HOST-NAME), you meet the login screen (unless you have a direct link to an App with Public Access). Upon login, if authentication succeeds, your User's Roles are evaluated.

First off, Appfarm evaluates if your (user's) Role(s) have access to log in the the Environment you are trying to access. The configuration of login access vs environments is configured from Permissions > Login.

If your Role(s) have access to more than 1 App, a splash screen for App selection will be presented. If only 1 App is available to you, you will be redirected to it automatically.

When accessing the App, all App Data is read. But only data of those Object Classes allowed to read for your Role(s), as defined in Permissions > Object Classes. When using the App, updates, create and delete of App Data will only be allowed if your Role(s) have those Permissions. In other words, you may have access to Read data of an Object Class, but not Update it.

When setting up logic in your App, you may access the properties of the logged-in user from the built-in Data Source (found in App Data) called Current User. When logging into an App, the Current User is you.

Adding Users for access to Create

Users may be manually added from the menu Users. Providing a User with one of the built-in roles Owners, Maintainers or Developers will give them access to Create. Owners have full access inside Create, being able to add other Owners as well. You may view the settings for access within Create from the menu Permissions > Advanced. If you are to add a User with a custom access to Create, you need to add a Custom Role for this, and adjust the Create access from the Advanced Permissions section.

Adding Users from your Apps (with access to the client)

Obviously, you could create a Custom Role with access to your Apps, and add these User manually from Create.

However, most solutions need an App with functionality for adding or removing Users.

The built-in User object may not be extended with additional properties. In most cases, you would need to create a Person Object Class. This Object Class should at least have a property User with data type User, and may have other properties, such as Company or Department, or Privacy policy accepted. Note: The built-in User object will soon be possible to enrich with custom properties as well, but for now you need a dedicated Object Class for this purpose.

Adding a new User to your App, would in the above example, require some UI to Create a new Person. For example, a dialog for entering First Name, Last Name and Login (email). Clicking the SAVE button should create a new User (action node Create User Account)

• We have runtime properties on the Person object for holding First Name, Last Name and Email temporarily. In our example, these properties should only be saved on the User object. You might save these properties to the Person object as well (adding these 3 properties as Object Class Properties of the Person Object Class)

• These properties are copied down to the User object created using Data Bindings

• We assign a Role App Users in the Role Memberships setting

• Accept Existing User is ticked. This means, if the User object is already created (e.g. added manually in Create or added from Dev or Test environments), the User object will just be read and updated with the correct Role (defined by the setting Add Roles being ticked).

• Add to Data Source: We have a runtime-only Data Source (cardinality One) for the purpose of holding the User object just created (or read, if already existing). We need this for updating the reference Person.User to point towards this User object in the next step.

• Optionally, you may tick the Send Welcome Mail. A default welcome mail will be sent to the User. The Welcome Mail content may have overrides defined from the menu Environment Config (see this section). Or you could just create your own welcome email using the Send Email action node.

Once this action node has succeeded, the User just created exists in the User database with correct permissions.

The Person object is not yet saved. This Action Node (Create Object) creates the Person object, with reference to the User object just created. The next Action Node Persist saves the Person object to the database.

Updating Users from your Apps

Updating Users from your Apps is explained following the same example as above.

Note that Updating a User's Email property must be done by removing the User object (Delete User Account) and Create a new user account using Create User Account.

You could reuse your UI for creating a Person. Edit a Person is typically done from a Table listing all Persons. Before opening the dialog for editing, just read the object in context into the Person (temp) Data Source! And if properties First Name and Last Name are not stored on the Person Object Class, just update these 2 runtime-only properties on the Person (temp) Data Source (from Person (temp).User.First Name, Person (temp).User.Last Name) before opening the dialog as well.

The SAVE button could trigger an action as follows:

Executing this action will update for First Name and Last Name of the User.

Removing Users from your Apps

Action Node Delete User Account allows you to delete a user. But note that doing this from Development or Test environment, for a User that is using the Production, will delete the User for good - leaving the User without possibility to access the Production environment anymore. Therefore, a good policy is to disable Delete User globally for Dev and Test environment (defined in the User Account Manipulation setting of Environment Config, also explained below).

If you do not want to permanently Delete the User, you could instead perform an Update User Account, and remove all permissions. This may be done by applying all roles in the Remove Roles setting of the Update User Account action node (see screenshot for Update User Account above).

Enable User Account Manipulation setting in Environment Config

Each environment has a global setting found in Environment Config > ENVIRONMENT. By default, user manipulation from Apps is only enabled for Production environment. When testing your functionality for adding or updating Users from either Develop, Test og Staging environment, you need to tick the checkboxes found in Environment Config > ENVIRONMENT, as illustrated below.

Setting to allow User Account Manipulation, to be turned ON

Enable which Role may update or create user accounts

From the menu Permissions > ACCOUNTS AND ROLES, you need to define which Roles are allowed to Create, Update or Delete User Accounts. This setup applies to user manipulation from the Client only, not from Create.

Handling Service Accounts

Service Accounts are users without a username and password. Service Accounts are added manually from Create - no action node exists for adding them from Apps.

Service Accounts are members of one or more Roles, similar to Users. They follow the same principles with regard to Permissions. But the normal use case for Service Accounts is that they are member of a dedicated Role, and this Role has access to one or more Services.

See this section for more info on handling Service Accounts.