Skip to content

feat: /report_usages route and the usage_data_opt_out shared setting [User issue investigation] - #52

Open
PetrDlouhy wants to merge 2 commits into
mainfrom
claude/usage-report-route
Open

feat: /report_usages route and the usage_data_opt_out shared setting [User issue investigation]#52
PetrDlouhy wants to merge 2 commits into
mainfrom
claude/usage-report-route

Conversation

@PetrDlouhy

Copy link
Copy Markdown
Contributor

Why

Two things from the review of BlenderKit/Blendkit#2296 (the add-on's save/render presence report):

  • @agajdosi: a frequent, specialised report must not ride the general-purpose wrappers/nonblocking_request task type. It now has its own route and task type, like every other route here.
  • @Tweekazoid (#add-on, 2026-09-10): data collected on the user's machine needs an opt-out, in one place shared by every host, not per add-on. That place is the Client's shared settings.

What changed

  • POST /report_usages (+ versioned alias): forwards the report field untouched to /api/v1/scene_save_reports/ with the standard headers as a report_usages task; finish/error come back through the task stream like ratings/send_rating. Anonymous add-ons send no Authorization.
  • Shared.usage_data_opt_out (bool, zero value = keep sending, so existing installs are unaffected). Set via POST /settings/set {"usage_data_opt_out": true}, broadcast in the settings snapshot on every /report. The Client enforces it: with the opt-out set, /report_usages answers 200 and creates no task.
  • API spec entry, regenerated docs/API.md / docs/openapi.json, five tests (usage_report_test.go). go vet, gofmt, full suite green under Go 1.26.

Deliberately not done

  • Only the usage report is wired to the setting. /report_event (login-funnel telemetry) is also machine-side data and is the obvious next candidate, but that is a product decision: @Tweekazoid, your call whether it goes under the same switch.
  • No UI. Each host exposes the toggle in its own preferences and writes it through /settings/set; the Blender add-on does that in Blendkit#2296.

Release

The add-on pins the v1.12 minor and resolves the patch at build time, so a patch release with this is picked up by the next add-on build. Blendkit#2296 must not be released before that.

🤖 Generated with Claude Code

The Blender add-on's save/render presence report (BlenderKit/Blendkit#2296)
had no Client route of its own and rode the generic non-blocking
wrapper, which agajdosi rejected. /report_usages forwards the `report`
field untouched to the server's /api/v1/scene_save_reports/ as a
"report_usages" task, like every other specialised route.

Sending usage data from the user's machine needs an opt-out that every
host shares (Blender, Maya, Unreal, Godot...), so it is a Shared setting,
`usage_data_opt_out`, settable through /settings/set and broadcast with
the settings snapshot. The Client enforces it: with the opt-out set,
/report_usages drops the report without creating a task, so a host
add-on cannot forget to honour it. Zero value keeps sending, so
existing installs are unaffected.

Only the usage report is wired to the setting; whether /report_event
(telemetry) should follow is Michal's call.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@PetrDlouhy PetrDlouhy self-assigned this Sep 10, 2026
@Tweekazoid

Copy link
Copy Markdown
Contributor

za me dobry,

jen je potreba prvne mergnout tohle do mastru a potom updatovat branch v addonu na main opet.

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.

2 participants