Settings#

sys-admin

Overview#

sys-admin

This topic describes the system level settings configurable via the Settings page, where a sysadmin user with access to the data/Settings model can view and modify the following global system level settings for Automate:

../../_images/admin-menu-settings-global.png

Note

Provider admins and admins at hcsadmin have access to the System Settings page (view/DataSettings) for managing transaction log levels only - this page is available via the default menus, Administration Tools > System Settings, and is a limited version of data/Settings.

../../_images/admin-tools-system-settings.png

Configure Transaction Log Levels#

System transaction log levels refer to the configured verbosity level of the transaction logs in Automate. Available transaction log levels for Automate are as follows:

  • Debug

  • Verbose

  • Info (default)

  • Warning

  • Error

  • Disabled

Note

See Transaction Log Levels for details.

The following Automate admin users can view and modify transaction log levels in Automate:

  • Provider admins and hcsadmin admins with access to the view/DataSettings model (default menus, Administration Tools > System Settings)

  • High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings)

Supported File Extensions#

Users with system administrator privileges to the data/Settings model, typically, sysadmin, can manage valid file extensions in Automate.

By default, the following file extensions are specified as supported in the Global instance of data/Settings, which means that files with these extensions can be uploaded to Automate.

  • .cer

  • .crt

  • .der

  • .gzip

  • .json

  • .key

  • .pem

  • .xlsx

  • .xml

  • .zip

  • .png

  • .jpg

  • .jpeg

  • .wav

  • .csv

  • .ico

The sysadmin user can add or remove file extensions. Unsupported files can’t be uploaded or imported, and will trigger a system error.

Disable Device Logging#

Users with system administrator privileges to the data/Settings model, typically, sysadmin, can enable or disable device logging.

When setting Disable Device Logging to enabled (on the Settings page). then CUCM AXL (and other external calls) requests and responses aren’t written to the transaction log, and neither are generic driver requests, responses, template evaluations, and macro evaluations. These details won’t display for the relevant transactions under Administration Tools > Transaction Log.

Activate Phone Status Service#

High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings) can view and update the Activate Phone Status Service checkbox, which is enabled by default.

When enabled, this setting indicates that the real-time information (RIS) data collector service is enabled and is polling the CUCM to obtain the latest phone registration status information for phone instances stored in the Automate database. The polling default interval is 43200 seconds (12 hours).

For details, see (Metrics Collection) page.

However, When viewing a list of phones, the status action can be carried out by an administrator who has been assigned a role that has an access profile to enable this action. By default, an administrator above provider level can carry out this task from the Role Management > Access Profiles menu - in this case, for relation/SubscriberPhone.

../../_images/access-profile-relation-subscriberphone-status.png

Carrying out this operation fetches the Unified CM phone IP address and status directly from the Unified CM and displays the data on the Phones list view Registration Status and IP Address columns, updating any existing data shown.

Important

Since the result of the status action is in real time, the current status of the list requires that the action carried out in order to see the latest values.

There is no caching of data resulting from this action. If any values show in the columns before carrying out this action, these would not be current, but are the cached values from the RIS data collector if it is enabled.

When carrying out the status action, the data in the Registration Status and IP Address columns can only be viewed.:

  • The latest data only shows for the current list of phones on the GUI.

  • The data in these columns is not stored in the database and cannot be exported.

../../_images/RIS-API15.png

Note

  • Whether the real-time information (RIS) data collector service is enabled or disabled, if the status action is carried out from the phones list view, the operation will always fetch and display the current information for the displayed phones directly from the device.

  • The administrator’s access profile associated with the role needs to allow the administrator to carry out the status action.

  • The carrier-integrated Mobile device type is automatically added to the RIS API Excluded Device Types and therefore not fetched by the service.

When clearing or enabling the check box on data/Settings, log in on the platform command line interface (CLI) and restart the service:

$ cluster run application app start voss-risapi_collector

Phone Status Service in the Logs#

When clearing this setting and then restarting the (RIS) data collector service, an app.log entry will show: "message":"RIS API service disabled".

Refer to the Platform Guide for commands to inspect log files.

Example log entry below (line breaks added):

2020-03-26T20:06:00.346577+00:00 VOSS-UN-2 deviceapi.background.risapi INFO
 {"process_id":24,
  "hostname":"VOSS-UN-2-voss-risapi-collector",
  "name":"deviceapi.background.risapi",
  "level":"INFO",
  "utc_iso_timestamp":"2020-03-26T22:06:00.346268",
  "request_uuid":null,
  "user_hierarchy":null,
  "user":null,
  "message":"RIS API service disabled",
  "line":330,
  "parent_process_id":1
 }

Additional Role Access Profile Validation#

High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings) can view and update the Additional Role Access Profile Validation setting to manage the available roles when an administrator creates access profiles.

The table describes how the system works when the Additional Role Access Profile Validation setting is enabled or disabled:

Enabled

An admin can only assign a role to a user if it is linked to an access profile with permissions that are in the subset of the admin’s own access profile. Role drop-down lists will therefore be restricted.

If the macro function fn.filter_roles_by_user_access_profile is used, the setting needs to be enabled for roles to be filtered.

This validation check also applies when admins manage multi-role admin users - where the role is associated with an Authorized Admin Hierarchy.

Disabled

(Default) An admin can assign any role to a user, regardless of the admins own access profile. Role drop-down lists will therefore not be restricted.

If the macro function fn.filter_roles_by_user_access_profile is used, the roles will not be filtered.

This validation check also applies when administrators manage multi-role admin users - where the role is associated with an Authorized Admin Hierarchy.

Note

See the macro topic Filter Role Functions for details on the use of the fn.filter_roles_by_user_access_profile function.

File Upload Limitations#

High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings) can view and update file upload size limitations and file time to live on the database.

By default, the following file limitations apply:

  • Maximum Upload File Size: 209715200 bytes (200MB)

  • Time-To-Live for Uploaded Files: 24 (clean up every 24 hours)

Note

  • Extending the Maximum Upload File Size to greater than the default can impact the platform system operation.

  • The minimum setting for time-to-live hours is 1 hour

Files are uploaded to the system database during activities such as:

  • Bulk Load

  • JSON import

  • Theme upload

  • Any other file upload activity, excluding:

    • Themes

    • SSO certificates

    • SSO service provider metadata

    • Audio files (MoH)

The time-to-live value applies to uploaded files that have not been used, in other words, imported or processed. By default, a check is done every 24 hours for such files, after which time they are removed.

Time-To-Live for Uploaded Files#

High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings) can view and update the time-to-live for uploaded files.

Note

Files uploaded from file management menus on the Automate GUI and listed as instances of data/File are not affected.

Uploaded bulk load files and imported JSON files are affected; however:

  • For bulk load files, the file is kept for as long as there is an instance of data/BulkLoad attached to it. So a schedule that is more than 24 hours in the future is not impacted, because when we schedule a bulk load for the future, we create a data/BulkLoad instance. The instance is cleared when the bulk load is executed.

  • Monthly license reports that are uploaded to the database by the internal schedule are not removed. For more details, refer to the License Guide.

Data Sync Workflow Execution Control#

High level admins (sysadmin) with access to the data/Settings model (default menus, Administration Menu > Settings) can view and update lists of device attributes affected by data sync in the Data Sync Workflow Execution Control settings (allowlist and denylist attributes):

Allowlist Attributes

When this list contains a field, then only a change in that field and not any other field will trigger data sync workflows, regardless of the list of the Denylist Attributes. In other words, this list takes precedence over the existing list of Denylist Attributes.

Denylist Attributes

Items in this list will not trigger any update workflows that may have been defined to execute during the data sync. These attributes are therefore excluded from data sync considerations.

The reason for this list of attributes is that while data sync operations can have a performance impact, some data sync attribute changes do not require data sync workflows to be carried out.

Note however that the local device cache will still be updated with the updated attribute data. No update workflows will be run, though. The transaction logs will indicate the updated device cache, but the transactions for these attributes instances will show as:

Device changes on denylisted attributes only. Updating cache, skipping workflows.
../../_images/data-sync-workflow-execution-control.png

Related Topics

Device Overwrite Check Exemptions#

High level admin users (sysadmin) with permissions to access the Global instance of the settings in the data/Settings model can create a list of fields to be excluded from device overwrite checking.

This means that if the field changes on the device, it will not be overwritten by data in VOSS Automate. The most common situation where this might be necessary is where a device field changes, but does not affect the data on VOSS Automate, because the data is treated as read only in VOSS Automate.

../../_images/device-overwrite-check-exemptions.png

Enable Wingman Chat#

High level admin users (sysadmin) with permissions to access the Global instance of the settings in the data/Settings model (default menus, Administration Menu > Settings) can enable or disable the VOSS Wingman AI assistant or copilot.

By default, Enable Copilot Chat is enabled, and the Wingman icon displays on the Admin Portal toolbar, if the user role is associated with an access profile that has Copilot Chat enabled under the Miscellaneous Permissions.

Refer to the VOSS Wingman topic in the Core Feature Guide.

../../_images/settings-enable-copilot-chat.png