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 via the **Access Profiles** page - in this case, for ``relation/SubscriberPhone``. .. image:: /src/images/access-profile-relation-subscriberphone-status.png Carrying out this operation fetches the UCM phone IP address and status *directly* from the UCM 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*. .. image:: /src/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-logs: 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: Additional role access profile validation .......................................... High level admins (``sysadmin``) with access to the ``data/Settings`` model (**Settings** page) 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: .. tabularcolumns:: |p{3.5cm}|p{10.5cm}| =============== ==================================================================== 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: File upload limitations ............................ High level admins (``sysadmin``) with access to the ``data/Settings`` model (**Settings** page) 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: Time-to-live for uploaded files ................................. High level admins (``sysadmin``) with access to the ``data/Settings`` model (**Settings** page) 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: Data sync workflow execution control ........................................ .. _20.1.1|EKB-6669: .. _19.3.4|EKB-6669: .. _21.4-PB1|EKB-15454: .. _21.4-PB1|EKB-15520: .. _21.4-PB2|EKB-15513: .. _21.4-PB2|EKB-15754: .. _24.1|EKB-12919: High level admins (``sysadmin``) with access to the ``data/Settings`` model (**Settings** page) can view and update lists of device attributes affected by data sync in the **Data Sync Workflow Execution Control** settings (allowlist and denylist attributes): .. tabularcolumns:: |p{5cm}|p{10cm}| +----------------------+------------------------------------------------------------------------------------+ | List | Description | +======================+====================================================================================+ | 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.* | +----------------------+------------------------------------------------------------------------------------+ .. image:: /src/images/data-sync-workflow-execution-control.png .. rubric:: Related topics * .. raw:: latex Allowlists and Denylists in the Core Feature Guide. .. raw:: html Allowlists and Denylists * .. raw:: latex Microsoft syncs in the Best Practices Guide. .. raw:: html Microsoft syncs .. _device-overwrite-check-exemptions: Device overwrite check exemptions .................................. .. _21.1|EKB-10048: 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 Automate. The most common situation where this might be necessary is where a device field changes, but does not affect the data on Automate, because the data is treated as read only in Automate. .. image:: /src/images/device-overwrite-check-exemptions.png .. _enable-wingman-chat: Enable Wingman chat ...................... .. _24.1|VOSS-1365: High level admin users (``sysadmin``) with permissions to access the *Global* instance of the settings in the ``data/Settings`` model (**Settings** page) can enable or disable the **VOSS Wingman** AI assistant or copilot. By default, **Enable Wingman 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 **Wingman Chat** enabled under the **Miscellaneous Permissions**. See *VOSS Wingman* in the Core Feature Guide. .. image:: /src/images/settings-enable-copilot-chat.png .. _wingman-web-proxy: Wingman web proxy ..................... High level admin users (``sysadmin``) with permissions to access the *Global* instance of the settings in the ``data/Settings`` model (**Settings** page) can select a Web Proxy name that has been added as an instance on the **Web Proxy** menu and which will be used by VOSS Wingman on environments that require web proxy access to the internet. .. image:: /src/images/settings-wingman-web-proxy.png .. rubric:: Related topics * .. raw:: latex "Set up a web proxy" in the Core Feature Guide. .. raw:: html Set up a Web Proxy * .. raw:: latex VOSS Wingman in the Core Feature Guide. .. raw:: html VOSS Wingman Portal Preferences ................... The **Portal Preferences** settings define system-wide settings for your environment. The table describes the available settings: .. tabularcolumns:: |p{5cm}|p{10cm}| +-----------------------+------------------------------------------------------------------------------------+ | Setting | Description | +=======================+====================================================================================+ | Application Insights | Enables/disables Automate product usage event tracking. Enabled by default. | | | Clear the field to disable event tracking. | | | | | | When enabled, the system securely tracks and measures anonymized product usage | | | events, | | | such as login/logout actions, user hierarchy, platform ID, locality, and browser | | | type. Additional tracked events include console errors, transaction types | | | (add/update), transaction status (success/fail), and the names of dashboards, list | | | views, and forms opened/closed. Event tracking in list views includes the number | | | of results returned and filter operators used (for example, "contains", "equals"), | | | but not filter values. Wingman queries are excluded, with only the number of | | | queries recorded. This data helps VOSS gain insights into product usage and | | | improve user experience. | +-----------------------+------------------------------------------------------------------------------------+ | Tooltip Display Event | Defines the action (event) that allows tooltips to display. You can choose to have | | | tooltips display for form elements only when using keyboard navigation (focus), or | | | only with mouse-over (hover) over the form element, or for both hover and focus, | | | or neither hover or focus (that is, no tooltips). | +-----------------------+------------------------------------------------------------------------------------+