App development and customization

Overview

DevOps lifecycle

Typically the app iterates through the following cycles:

1. Developing
   1. Developers can change the app and preview in the DEV-environment (dev-server).
   2. During the developments various app-settings variables can be introduced for further handy tailoring of the app by system admin, by workspace admins or personalized by users.
   3. When the app is ready for user-testing or production-usage - it is marked as released and can be further deployed by the system admin.
2. Deployed
   1. System admin can pick the available developed apps and deploy them to the production usage.
   2. System admin can also configure the deployment-app-settings which will influence how the app will look and operate.
3. Installed
   1. Workspace admins can select available deployed apps and install them into their managed workspace.
   2. Workspace admins are responsible for customizing the app-workspace-settings available for the app.
   3. Some apps will also support personalization app-settings - private users' settings which will define user-specific look or behavior of the app.

App settings levels

The app has 3 main levels where app-settings are applied

1. App-system-settings
   1. Also known as: deployment-settings, compile-time settings, system-constants, preprocessing-variables, precompiled-settings.
   2. Only system admins can change these settings. Workspace admin can NOT change this type of settings to be different in their own workspaces.
   3. In case the system-settings are changed - the app will be redeployed (recompiled) with these new settings.
   4. These settings changes will result in updated app look and behavior in all the workspaces where this app is installed.
   5. The system-settings can parameterize any aspect of the app - the data model, user-interface or behavior.
2. App-workspace-settings
   1. Also known as: app-installation-setting or workspace-specific-settings
   2. Only workspace-admins can change these settings for the workspaces which they administrate. Workspace admins can not change these settings for other workspaces.
   3. When workspace-specific settings are changed - the app is not redeployed or reinstalled, but the changes will immediately be applied for the end-users of the particular workspace.
   4. Unlike app-system-settings the app-workspace-settings can not change all the aspects of the app - for example they can not change core data-model attributes like field types or availability of the fields in the app. However most of the other app aspects can be parameterized by these settings: from the user-interface or the actions logic.
3. App-personalization-settings
   1. Also known as: users-specific-settings
   2. Sometimes the app can have specific settings controlled by individual users, which will allow various customizations for the app look and logic - either per-user per-workspace (when workspace is defined) or just per-user for all the workspaces where the app is installed (when workspace is empty).

App settings types

1. Common app-settings
   1. These settings are system-wide and available in every app, they usually control various UI aspects. Examples are: hiding conversation/history in the form or disabling email notifications for the app.
2. App-specific variables
   1. These settings are introduced by the app developer to customize certain aspects of the particular app. Examples are: currency for the app field, the name of the default assigned user or default visibility of the newly created records.
3. App-specific secrets (often called "secret variables")
   1. These are the same as "variables" but which must be kept in secret. The system can use it only in the server context and never sends to the user browser. Examples are: special authentication tokens to connect to external systems - or any passwords/credentials.

App settings - admin usage

System admin has 2 ways to deploy apps to Comind:

1. Direct deployment - with specific command line which will compile the app from the source-code and apply any variables stored in the .env file
2. App-editor deployment - when the app is updated either in the web-environment (or code changes are pushed from the local environment) and the app is compiled online with respect of the app-system-settings edited in app-editor app.
   1. Customized settings are NOT part of the code, they can not be pulled.
   2. Changing of the setting will NOT change the code (unlike changes of fields or layouts)

The mixed usage is also possible - but the admin should manually prevent the possible difference between locally stored settings and the edited in the web to avoid different app configuration.

App settings - developer usage

Developers are encourage to introduce app-settings to give additionally flexibility for the system-admins and workspace-admins, which will allow the change how the app looks and works without the need to request source code changes from the app-developer.

Methods to use

1. App-system-settings
   1. "import" in the source-code
   2. Updating app-structure in the app-mutator (any aspect of it)
2. App-workspace-settings
   1. By calling Cmw.getVars in code - which will return the value for the currently used workspace
   2. Note that using such settings with "import" (like for app-system-settings) is incorrect and will not return the right workspace setting.

Examples

For data-model (fields) customization

• Field attributes change - caption, default value, prefix, mask, help-text, etc
• Reference field target workspace / app
• User lookup restriction by group

For actions customization

• Action attributes change - caption, visibility, help-text, etc
• Variables for group-names used in preconditions

For operations or calc-fields

• Variable used in calculation of calc-field
• Variable URL to external service
• Variable auth credentials to external service