Currently telemetry settings are exclusively controlled via the custom redhat.telemetry.enabled setting, which needs to be specified in each Red Hat extension's package.json as a configuration property, leading to warning messages in the Developer Console when multiple Red Hat extensions are installed, as e.g. reported here:
[redhat.vscode-yaml]: Cannot register 'redhat.telemetry.enabled'. This property is already registered.
The official Telemetry extension authors guide mentions in Without the telemetry module:
Extension authors who wish not to use Application Insights can utilize their own custom solution to send telemetry. In this case, it is still required that extension authors respect the user's choice by utilizing the isTelemetryEnabled and onDidChangeTelemetryEnabled API. By doing this, users will have one centralized place to control their telemetry settings.
and then in Custom telemetry settings:
Adding a custom telemetry setting is not an exemption from respecting a user's decision and the isTelemetryEnabled and onDidChangeTelemetryEnabled flag must always be respected. If isTelemetryEnabled reports false, even if your setting is enabled, telemetry must not be sent.
The mentioned isTelemetryEnabled boolean setting is part of the VS Code API's dev namespace: https://code.visualstudio.com/api/references/vscode-api#env
Would it be feasible to eventually migrate over to the global setting or are there other concerns around this?
Currently telemetry settings are exclusively controlled via the custom
redhat.telemetry.enabledsetting, which needs to be specified in each Red Hat extension'spackage.jsonas a configuration property, leading to warning messages in the Developer Console when multiple Red Hat extensions are installed, as e.g. reported here:The official Telemetry extension authors guide mentions in Without the telemetry module:
and then in Custom telemetry settings:
The mentioned
isTelemetryEnabledboolean setting is part of the VS Code API'sdevnamespace: https://code.visualstudio.com/api/references/vscode-api#envWould it be feasible to eventually migrate over to the global setting or are there other concerns around this?