Bug
The analytics page's date range picker (date_from/date_to) is respected by the on-screen charts but silently ignored by the CSV download endpoints, even though the frontend sends the same query params to both.
download() in Analytics.jsx builds its query string the same way as the charts (course_id, date_from, date_to, granularity):
https://github.com/AvaCodeSolutions/django-email-learning/blob/master/frontend/platform/analytics/Analytics.jsx#L326-L329
But on the backend, none of the three download views call the _date_range() helper that the chart endpoints use:
Each only applies _course_ids(request) via _enrollment_qs/_delivery_schedule_qs, so course_id filtering works correctly but the export is always all-time regardless of what's selected in the date pickers.
Decision
After discussion, only the two detail-log downloads should honor the date range — they're per-row exports, so a user picking "last 7 days" and downloading reasonably expects the export to match what's on screen:
DownloadCompletionSummaryView should stay all-time and NOT get date filtering — it's a per-course aggregate summary, consistent with the other breakdown/summary endpoints (EnrollmentStatusBreakdownView, CompletionFunnelView, AverageProgressView, TimeToCompleteView, EmailOpenRateView) which are also intentionally all-time and don't call _date_range().
Fix
Add date_from, date_to = _date_range(request) plus the corresponding .filter(...) to DownloadLearnerProgressView and DownloadDeliveryLogView only.
Bug
The analytics page's date range picker (
date_from/date_to) is respected by the on-screen charts but silently ignored by the CSV download endpoints, even though the frontend sends the same query params to both.download()inAnalytics.jsxbuilds its query string the same way as the charts (course_id,date_from,date_to,granularity):https://github.com/AvaCodeSolutions/django-email-learning/blob/master/frontend/platform/analytics/Analytics.jsx#L326-L329
But on the backend, none of the three download views call the
_date_range()helper that the chart endpoints use:DownloadLearnerProgressView— https://github.com/AvaCodeSolutions/django-email-learning/blob/master/django_email_learning/analytics/views.py#L373-L425DownloadDeliveryLogView— https://github.com/AvaCodeSolutions/django-email-learning/blob/master/django_email_learning/analytics/views.py#L428-L471DownloadCompletionSummaryView— https://github.com/AvaCodeSolutions/django-email-learning/blob/master/django_email_learning/analytics/views.py#L474-L530Each only applies
_course_ids(request)via_enrollment_qs/_delivery_schedule_qs, socourse_idfiltering works correctly but the export is always all-time regardless of what's selected in the date pickers.Decision
After discussion, only the two detail-log downloads should honor the date range — they're per-row exports, so a user picking "last 7 days" and downloading reasonably expects the export to match what's on screen:
DownloadLearnerProgressView— filter enrollments byenrolled_at__datewithin[date_from, date_to], matching the fieldEnrollmentsOverTimeViewalready filters on (https://github.com/AvaCodeSolutions/django-email-learning/blob/master/django_email_learning/analytics/views.py#L109).DownloadDeliveryLogView— filter delivery schedules bytime__date(the scheduled date) within[date_from, date_to]. Note: don't filter ondelivered_at, since that's null for scheduled/failed rows and would silently drop them from the log;timeis always set.DownloadCompletionSummaryViewshould stay all-time and NOT get date filtering — it's a per-course aggregate summary, consistent with the other breakdown/summary endpoints (EnrollmentStatusBreakdownView,CompletionFunnelView,AverageProgressView,TimeToCompleteView,EmailOpenRateView) which are also intentionally all-time and don't call_date_range().Fix
Add
date_from, date_to = _date_range(request)plus the corresponding.filter(...)toDownloadLearnerProgressViewandDownloadDeliveryLogViewonly.