VideoGame was missing from the API router, causing
HyperlinkedModelSerializer to fail when generating URLs for scrobble
relationships.
Changes:
- Create videogames/api/ with serializers and views
- Register VideoGameViewSet at /api/v1/videogames/
- Register VideoGameCollectionViewSet at /api/v1/videogame-collections/
- Register VideoGamePlatformViewSet at /api/v1/videogame-platforms/
TrailViewSet and FoodCategoryViewSet were imported but never registered
in the DRF router, causing HyperlinkedModelSerializer to fail when
trying to generate URLs for scrobble relationships.
Changes:
- Add router.register(r'trails', TrailViewSet)
- Add router.register(r'food-categories', FoodCategoryViewSet)
The ScrobbleViewSet was using lookup_field="uuid" which caused
API detail views to fail for scrobbles with NULL UUIDs. Rather
than backfilling all NULL UUIDs, switch to pk lookup which is
always populated.
Changes:
- Remove lookup_field="uuid" from ScrobbleViewSet (defaults to pk)
- Remove extra_kwargs from ScrobbleSerializer (URL now uses pk)
- Update regenerate_share_token action signature to use **kwargs
The ScrobbleSerializer uses HyperlinkedModelSerializer with
lookup_field='uuid', but 3,273 of 6,155 Scrobbles had NULL UUIDs,
causing URL resolution to fail.
Fix:
- Add migration 0104 to backfill NULL UUIDs with uuid4()
- All Scrobbles now have valid UUIDs for URL resolution
Same issue as drink-detail: Paper model had a template URL but no API
ViewSet, causing HyperlinkedModelSerializer to fail.
Fix:
- Add PaperSerializer and PaperViewSet to books/api/
- Register PaperViewSet as 'papers' in the DRF router
HyperlinkedModelSerializer could not resolve drink-detail because no
API ViewSet existed for the Drink model, even though the template URL
existed in drinks/urls.py.
Fix:
- Add DrinkSerializer and DrinkViewSet to drinks/api/
- Register DrinkViewSet as 'drinks' in the DRF router (vrobbler/urls.py)
- Mark task 8f2a3b4c as DONE in PROJECT.org
GET /api/v1/scrobbles/ now resolves without error.
GET /api/v1/scrobbles/ fails because HyperlinkedModelSerializer
can't resolve drink-detail — no API ViewSet exists for it, only a
template view in drinks/urls.py.
Closes #2fddd5d0-1138-4a6e-96b7-5879035f033f
drf-spectacular provides OpenAPI 3.0 schema generation for all 52
registered ViewSet endpoints under api/v1/. This is a prerequisite for
auto-generating the Kotlin networking layer.
Changes:
- Add drf-spectacular dependency (0.27.x)
- Register in INSTALLED_APPS and configure DEFAULT_SCHEMA_CLASS
- Add /api/schema/ (OpenAPI YAML) and /api/docs/ (Swagger UI) routes
- Add SPECTACULAR_SETTINGS with enum name overrides to suppress warnings
Schema generates cleanly with 4 non-blocking warnings (1 unique:
TagListSerializerField defaulting to string) and 14 unique skipped
errors (all non-ViewSet APIViews like webhooks that lack serializers).
- Add openfoodfacts Python SDK dependency
- Create foods/sources/openfoodfacts.py API wrapper with text_search
- Add off_code field + find_or_create_from_search() to Food model
- Add nutrition fields (protein, fat, carbs, fiber, sugar, sodium),
ingredients, image, off_code to Drink model
- Create FoodSearchView and FoodScrobbleFromSearchView at /foods/search/
- Route beverages to Drink model based on OFF category keywords
- Update ManualScrobbleView to redirect '-f Food Name' to food search
- Add Drinks section to home page and scrobble detail templates
- Update drink_detail.html with nutrition grid and image display
Add referrerPolicy: 'origin' to the Leaflet tile layer in
geolocation_list.html and geolocation_detail.html to match the
other four templates that already had it.
Without this, those templates send the full page URL as Referer,
which can trigger OSM rate limiting (osm.wiki/blocked error).
Also marks the task as DONE in PROJECT.org.
Add 'last_7' (Last 7 days) as a selectable period for all trends.
Changes are minimal since the period system is driven by PERIOD_CHOICES
and PERIOD_DAYS dicts — the rest of the infrastructure (views, templates,
Celery tasks, management commands) picks it up automatically.
- Add ('last_7', 'Last 7 days') to PERIOD_CHOICES in models.py
- Add 'last_7': 7 to PERIOD_DAYS in utils.py
- Migration 0004_alter_trendresult_period_add_last_7
The user_with_custom_thresholds fixture used UserProfile.objects.get_or_create()
which returns a separate Python instance from the one cached in
user._state.fields_cache['profile']. When the fixture modified and saved
the get_or_create instance, the cached instance on the user object still
held default values (periodic=16, full=24). compute_fasting() accessed
u.profile which returned the stale cached object.
Fixed by modifying through u.profile directly, which operates on the
same cached instance. Also applied black formatting to fasting.py.
- Replace day-iteration algorithm with pair-based approach for fasting
detection. Iterate consecutive food scrobble pairs and mark foodless
days between them as fasting days.
- Handle consecutive-day periodic fasting: when two food scrobbles are on
consecutive days with a gap >= periodic_threshold but < full_threshold,
mark the later day as a periodic fast (user's original bug fix).
- Fix _dt test helper to use replace() instead of subtracting hours,
producing correct timestamps (e.g., '3 days ago at 18:46' instead of
'3 days + 18h46m ago').
- Fix total_days off-by-one: removed +1 from inclusive day count so a
'last_30' period correctly reports 30 days.
- Add _drinks_on_day() for per-day drink detection (replaces whole-
window _drinks_in_window for more accurate liquid fasting detection).
- Fix Beer test fixture to use styles M2M field instead of non-existent
beer_style attribute.
- Add 26 test cases covering: classification, short gaps, periodic/
full/liquid fasting, multi-day gaps, vacation exemptions, custom
thresholds, streaks, mixed types, edge cases.
Reasoning:
The original day-iteration algorithm had fundamental issues: it marked
days with food as fasting (since it only checked prev/next food times),
it didn't filter out normal (< periodic) gaps, and the _dt helper was
misinterpreting hour parameters. The new pair-based approach is cleaner:
for each consecutive food scrobble pair, we mark the foodless days
between them. This naturally handles multi-day fasts and correctly
avoids marking food-eating days as fasting. The consecutive-day periodic
rule preserves the user's original intent of detecting overnight fasts
between meals.
- Try adding a nature app with Observations and Species
- Add ability to push one or sync all board game scrobbles to BGG
- Clean up naming of =bgsplay= parsing
