[barkerd427]

Proposed Changes

Adds a generic device value to MeasurementSource for data written by a wearable or sensor app on the user's behalf. Migration 0009 only changes the field's choices.

I'm writing heart rate from a Wear OS app into wger and didn't want to mark it as google or apple. device keeps the server from needing a source per vendor; the app can put vendor/model in extra_data.

Nothing else changes. device works through /api/v2/measurement/ and the PowerSync upload, filters with ?source=device, dedupes on the existing (category, source, external_id) constraint, and gets the same limits as any other source. The Flutter app treats source as a plain string, so these rows just show up as imported entries.

A bulk create endpoint would help for high-rate sensors, but that can be a separate PR.

Related Issue(s)

Related to #2417 and wger-project/flutter#1260.

Please check that the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Code has been formatted to avoid unnecessary diffs (ruff format && ruff check --fix)
• If the feature is big enough or if there are manual steps needed (deployment
  changes etc.), write a small writeup in CHANGELOG.md

[rolandgeider]

Yes, this makes sense, and could be used by openScale or BLE Scale, which already have integration with wger. I'll have to check how we derive the read-only flag, that makes sense when the data comes (possibly aggregated) from health sync, but less so if it's from your own scale

[barkerd427]

Thanks. I traced the read-only handling to save you the lookup. On the server, only calculated entries are locked: deletes get a PermissionDenied in the entry viewset and edits a ValidationError in the serializer. Everything else, google and apple included, is editable through the API. The read-only behavior users see comes from the app: entries.dart hides edit/delete for any source other than user and shows the "imported" icon instead.

That already does the right thing for device. The device is the only thing that should change its own entries, and it does that through the API with its own external_id, so a resend can't clobber anything: a second POST with the same external_id gets a 400 (the PR's test covers it) and a PowerSync resend with the same row id is ignored. So nothing on the server or in the app needs to change for this PR.

[rolandgeider]

alright, thanks for checking.

Now that I think a bit more about this, it's also possible that users connect e.g. their scales to health sync, then we would want those editable as well. Perhaps just showing some kind of info in the ui is the better / more general solution here. In any case, that's ui thing, and has nothing to do with this pr :)