Flagsmith / Flagsmith/flagsmith
Group organisation usage by project and environment in one request
- Dominant language
- Python
- Stars
- 6.6k
- Forks
- 567
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 121
Description
The usage dashboard can break usage down by request type and SDK, but not by project or environment. Those two need one request per key, and `GET /organisations/{id}/usage-data/` is throttled at five a minute per user, so any organisation with a handful of projects gets 429s.
The SDK dimension has no such problem because rows in `events_list` already carry `labels.user_agent`, so the frontend groups them client side off the one request the page has already made. Project and environment want the same shape.
**What we need.** One response that carries the per project and per environment split, rather than the caller asking once per key. Either:
- add project and environment to the labels on each row, so the existing client side grouping picks them up, or
- add `group_by=project|environment` returning one row per key
Whichever fits the analytics service better. The frontend only needs to be able to rank projects by usage without making N requests.
**Where things are**
- `api/app_analytics/views.py`, `get_usage_data_view`, carries `@throttle_classes([InfluxQueryThrottle])`
- `api/app_analytics/throttles.py`, scope `influx_query`, keyed on `user.pk`
- `api/app/settings/common.py`, `"influx_query": "5/min"`
- `api/app_analytics/serializers.py`, `UsageDataQuerySerializer` takes `project_id` and `environment_id` as filters today
- Both the Influx and Postgres paths in `api/app_analytics/analytics_db_service.py` would need it
**Why now.** #8186 shipped the breakdown with request type and SDK only. The project and environment dimensions are held back until this lands: a throttled scope reports nothing, and a breakdown that silently omits a project ranks the remaining ones wrongly.
Contributor guide
Research direction
Start in api/app_analytics/views.py at get_usage_data_view and trace the request through UsageDataQuerySerializer and analytics_db_service.py, including both Influx and Postgres paths. Review the existing request type and SDK breakdown from #8186, then verify the chosen response shape supports project and environment rankings from one request without per-key calls.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, python
- Domain
- analytics, api, backend, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 66/100