Skip to content

feat(install): ask about usage reports in the install scripts - #324

Merged
jakub-przepiora merged 1 commit into
developfrom
feat/ask-about-telemetry-in-installers
Sep 28, 2026
Merged

jakub-przepiora merged 1 commit into
developfrom
feat/ask-about-telemetry-in-installers

Conversation

@jakub-przepiora

Copy link
Copy Markdown
Contributor

The gap

Reporting became opt-in in 0.24.3, and the web setup wizard asks about it on its admin step.

A Docker install never reaches that wizard. docker-entrypoint.sh creates the admin account and writes storage/installed — a block whose own comment says "skip web installer". So nobody who installed with install.sh or install.ps1 has ever been asked. The question existed, on a screen that population does not see.

The part worth reading carefully

Writing OPENMES_TELEMETRY to .env is not on its own enough, and assuming it was would have produced a change that looked right and did nothing.

TelemetrySettings::enabled() treats the environment variable as a veto: set and falsy forces reporting off. What turns it on is the stored setting, and an absent row means off — "silence is not consent", as the code puts it.

So three pieces had to line up:

  1. install.sh / install.ps1 ask, and write OPENMES_TELEMETRY to .env.
  2. docker-compose.yml passes it into the backend container — which is where the scheduler that sends reports actually runs (started by the entrypoint on the primary, not in a sidecar). It was not in that environment: list, so without this the variable would have gone nowhere.
  3. docker-entrypoint.sh records the choice in system_settings, guarded on the application not being marked installed yet, so it can never overwrite a choice an administrator later makes in Settings → System.

Default is no

The prompt is [y/N], and an unattended run counts as a refusal rather than as consent — the same rule the application applies to a setting nobody ever set. Only an explicit y/yes opts in.

The prompt also states plainly what is and is not sent, so the answer is an informed one:

OpenMES can send information about the software: version, which features are switched on, rough size bands, and where errors occur. It never sends anything entered into the system — no order, product, customer or personal data. You can change this later in Settings → System.

Verified link by link

Check Result
Answers "", n, and a non-interactive run false
Answers y, yes, Y true
docker compose config OPENMES_TELEMETRY: "true" on the backend service
The entrypoint's snippet, against a real database writes true / false into system_settings.telemetry_enabled

Full suite: 2951 PHP tests, 173 JavaScript tests.

Scope

Additions only — 103 lines across the two install scripts, the compose file, the entrypoint and the changelog. No application code, so an existing installation is unaffected until it is reinstalled.

Reporting became opt-in in 0.24.3 and the web setup wizard asks about it on its
admin step. A Docker install never reaches that wizard: docker-entrypoint.sh
creates the admin account and writes storage/installed, which is explicitly
there to skip it. So nobody who installed with install.sh or install.ps1 was
ever asked — the question existed, on a screen that population never sees.

The prompt defaults to no, and an unattended run counts as no rather than as
consent, which is the same rule the application applies to a setting nobody
ever set.

Writing OPENMES_TELEMETRY to .env is not on its own enough, and that is the
part worth reading carefully. TelemetrySettings::enabled() treats the env var
as a veto — set and falsy forces reporting off — but what turns it ON is the
stored setting, and an absent row means off. So three pieces had to line up:

  - install.sh / install.ps1 ask and write OPENMES_TELEMETRY to .env;
  - docker-compose.yml passes it into the backend container, which is where the
    scheduler that sends reports actually runs (entrypoint, not a sidecar) — it
    was not in that environment list, so the variable would have gone nowhere;
  - the entrypoint records the choice in system_settings, guarded on the
    application not being marked installed yet, so it cannot overwrite a choice
    an administrator later makes in Settings → System.

Verified each link rather than assuming it: the prompt answers no to silence,
"", and "n" and yes only to y/yes; `docker compose config` shows
OPENMES_TELEMETRY reaching the backend service; and the entrypoint's snippet
writes true and false into system_settings.telemetry_enabled against a real
database.
@coderabbitai

coderabbitai Bot commented Sep 28, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)
  • cla-signed

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: Mes-Open/OpenMes/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 62687ee1-76f4-4b61-8f2e-59523f7de2bd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@jakub-przepiora
jakub-przepiora merged commit 9170490 into develop Sep 28, 2026
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant