TODO.md

• Write more tests and validations for Filter.
• Write validations and tests specific to the Dimensional lens
• Write validations and tests specific to the Time Series lens
• Write tests for the various #from_params methods
• Figure out a date picker UI for From/To.
  • Needs to support selecting absolute dates, and relative dates via expressions. Both should be able to be entered manually, or filled in based on suggested/common ranges. For example, the user should be able to select "Last 30 days" as both an absolute range, and as a relative range.
  • When working with relative expressions, the UI should show a hint as to what absolute time the expressions currently resolves to, so that the user can be confident they are writing the expression correctly.
  • The app always thinks in terms of "GTE From AND LT To". This does not necessarily have to be how the UI works for users. For example, we may want the user to be able to select "January 01" to "January 31" in the UI, if their desire is to select the entire month of January. If we want the UI behavior to differ from the app's internal behavior, we have to have a good plan for how to do that consistently and reliably.
• Figure out if we want to support time zones for the range selection at all. The app only thinks in terms of UTC.
  • I vote no, at least to start.
  • If/when we do want to support time zones at all, it must be done entirely on the client side, the from and to values in the URL query will always be UTC-only.
• Figure out a UI for filter multi-selects.
  • Things like podcast_id, country_id, timezone, etc.
  • While some of these are filtering on ID, the user should interact with something more friendly, like the podcast name.
  • The values available for these filters for any given user should probably be cached somewhere.
• Add validations for values that must be authorized, like podcast_id.
  • The app needs to ensure that it will never query a database for resources that the user isn't authorized to access. The UI should only present authorized values, but check them again before the query is actually sent.
• Figure out UI for Type=Duration filters, which allows the user to define a GTE-LT range. Internally, durations are always some number of seconds, but the user probably should be able to interact with hours/days/weeks/etc.
  • Months is tricky, if we want to include that it needs to be well-defined. I would vote for no months
• Figure out a UI for Type=Timestamp filters.
  • These filters work in two modes:
    • One mode allows the user to select a range, similar to the overall from/to range. The UI should be similar/identical, allowing for both absolute and relative selections, suggested ranges, etc.
    • The second mode allows the user to select a timestamp truncation (such as "day of week"), and then provide a list of value (such as "saturday" and "sunday"). This UI should be similar/identical to the UI for multi-select filters. Most users probably aren't familiar with how SQL truncate functions work, so this UI should help them understand what's going on.
  • The user needs to be able to select the mode, and then also input the values necessary for the selected mode.
• For lists of values in a query parameter, make sure that commas aren't escaped, to improve readability of the resulting URL.
• When the user selects "rolling" granularity for a Time Series lens, there needs to be a UI that allows them to define the rolling window. Currently the app expects that these windows will be at least 2 days, and will be a natural number of days, but there's not strict requirement. The app would also support a rolling window of 47 minutes, if we wanted. I suspect there is very little need for that, so to keep the UI simple, for now it should probably just support days
  • The value used in the URL query should still be seconds, but we should also support a value with a unit, like 14D for 14 days, to make the URL more readable.
• Figure out a UI when grouping by a dimension whose Type=Duration.
  • The UI should allow the user to set an arbitary number of ranges. Internally, there are always at least 2 ranges, the first range is LT X, and the second range is GTE X. If the user wants to add more ranges, the each work in this way, for example:
    • LT 10
    • GTE 10 and LT 30
    • GTE 30 and LT 90
    • GTE 90
      • In this example, the only numbers we need from the user are 10, 30, and 90.
      • The user only defines on side of each range, we can figure out the other from the previous range
  • So internally, there are some number N of index points, which result in N+1 ranges, and those ranges cover the the entire number line.
• Figure out a UI when grouping by a dimension whose Type=Timestamp.
  • These groups work in several modes:
    • One mode is ranges, and works the same as Duration ranges, but the values are dates or date/times.
    • Another mode is grouping based on an extracted value from the timestamp, such as day of week, or month.
      • The user selects the extraction part ("day of week", "month", etc), but not any specific values (like "monday" or "june").
    • A third mode is grouping based on a truncated version of the timestamp. The user selects a date/time part to truncate to (like "month" or "year")
• Finalize dimension names
  • These need to be consistent because changing them would break saved URLs, reports, etc
• If the user adds an exclude filter on an impression dimension (like advertiser), but only selects downloads as a metric, ensure that all downloads associated with that advertiser are excluded, even if there are other impression rows for that download for other advertisers.