Skip to main content

Settings

In iCL Portal, settings can be used to modify various aspects of how the system operates.

note

You need administrative privileges for this. The settings can be found in Settings/Settings

A setting is shown like the following in iCL Portal

  1. It provides a description that explains in detail, what the particular setting is about
  2. You can change the setting and save its value
  3. At any point, you can revert the current settings value to the default
  4. If it is a setting, that can be altered by a user, you will see the fourth button. It shows the number of users that actually changed this setting and are not using the value the administrator configured

Settings hierarchy​

To ease up setting management, they can be configured hierarchically:

  1. for all tenants of a system (host)
  2. for a specific tenant
  3. and for a specific user

Most of the settings can be altered at each hierarchy level. But there are also settings on level 1 only, like the database settings, that affect where the data of newly added tenants is to be stored:

Hierarchically changing a setting​

Hierarchically configuring a setting means the following.

  • If the host administrator changes a setting (level 1), then this setting is used as the default for each tenant and user.
  • As the default means, that a tenant admin sees this level 1 value as default value, meaning he can still change the setting even the host admin already changed it.
  • If at any point, the tenant admin chooses to reset that setting to the default value, the default value is in fact not the value that the host administrator provided. (Not the default value as defined in the software itself)
  • However, for the host admin, the default value will always be the one defined in the software (iCL Portal) itself.

In the same manner, settings (provided, they allow this) can be overwritten by any user.

Changing a user setting​

In the settings view for administrators, you can only specify host-wide or tenant-wide settings. While you can see how many users did overwrite a particular setting, you can only reset it to the default value, but you cannot set it to any arbitry one.

To do so, you need to find the user in the users list (Settings/Users), and via the context menu of a given user, choose Settings

There you will be able to change each and every of that users settings to any valid value.

Specifying tenant-wide Filler 2.0 settings​

Now, there is a list of settings, that should be changeable by each and every user. These can, amongst others, be found in the setting group Filler 2.0 settings:

Those are the very same settings, that can be changed in the iCL Filler 2.0 app's settings view.

This means, that a tenant administrator can configure the settings for each and every of the users in one single place.

Now, each user can still overwrite these settings by specifying them in the app's settings view. But as they are synchronized with iCL Portal, you can at any time reset those settings as an administrator.

Database settings​

Advanced topic for system admin

this is an advanced topic and can only be configured by the system (host) administrator!

danger

Any of these settings apply only to tenants that are created after those settings are applied. Changing any of these settings will not have any effect on any existing tenants! You will have to manually apply those changes to existing database (change their service level, join an elastic pool, etc.)

The following screenshot shows the list of database specific settings that can be configured by the host administrator

  1. When you set up a new tenant, by default, all that tenants data is stored in one central database. This is ok if you only intend to use the tenant for demonstration purposes, or if there is only very little data stored ever. In any other case, it is advisable to create a new database for each new tenant. This is now also the default setting (see 1)

  2. This setting is only an indicator showing whether or not the system is using Azure SQL Server. You cannot really change it. However, it is used by the following three settings to validate user input

  3. When a new database is created, you need to specify the service objective. This determines the DTUs (data transfer units) available to that particular database, and therefore, its price. If you do not configure anything, SQL Azure will default to an S0 instance which costs about 300€ per month (as of the time of this writing February 2022)

  4. Instead of specifying a service objective per database, Azure SQL allows to combine multiple databases in an elastic pool which can then utilize the available set of DTUs together. Given you plan to have many tenants and you do not know their database usage up front, pooling databases is the most cost-effective option.

    note

    When this setting is configured, it overwrites (3) - so the service objective, if configured, would be ignored

    note

    When you specify an elastic pool name, this pool must already exist. (Consult docs.microsoft.com on how to create a new elastic pool)

  5. The option backup storage redundancy allows to configure how durable any backups of new databases have to be stored. (Local, Zone, Geo - please consult docs.microsoft.com for more information on this)