Add filtering to GET /api/polls/ (is_active, created_by)

As the number of polls grows, "every poll, newest first" stops being useful for real clients -- a dashboard, a "my polls" management page, or a moderation view that only cares about currently-live polls all need to ask the API for a subset instead of fetching everything and filtering client-side. Client-side filtering doesn't even work correctly once pagination is involved (page 1 of "all polls" is not the same as page 1 of "my active polls"), so every consumer of this endpoint is stuck working around a gap that should be closed in the API itself.

GET /api/polls/ always returns every poll (paginated, 20 per page), newest first, with no way to narrow the list. PollViewSet.queryset is a static Poll.objects.all().select_related(...).prefetch_related(...) -- there is no get_queryset override reading anything from the request.

cd django/poll_app source .venv/bin/activate python manage.py runserver &

Assume alice has created one active and one inactive poll, and bob has

created one active poll (see

practicetickets/test_ticket04_poll_list_filtering.py for the exact fixture).

curl -s "http://127.0.0.1:8000/api/polls/?is_active=true" | jq '.results | length'

-> still returns every poll, active and inactive alike --

is_active is not read anywhere in PollViewSet.

curl -s "" | jq '.results | length'

ModelViewSet calls self.get_queryset() to build the base queryset for list() (and other actions); overriding it is the one place this kind of narrowing belongs. This is a foundational piece of API surface that a lot of realistic UI depends on, and it's currently entirely absent -- no stub exists to extend, because nothing resembling this exists yet.

ModelViewSet calls self.get_queryset() to build the base queryset for list() (and other actions); overriding it lets you start from the existing Poll.objects.all().select_related(...).prefetch_related(...) and narrow it based on self.request.query_params. Think about how to parse is_active as a boolean from a query string ("true"/"false" arrive as strings, not Python bools), what the queryset looks like when the param isn't present at all, and filtering created_by by username, not id -- the API never exposes a raw user id to clients (PollSerializer.created_by is source="created_by.username"), so a client can only reasonably send back the username it was shown, which means traversing the relation (created_by__username) rather than filtering on created_by_id.