Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-day date filter in sessions #3471

Closed
macobo opened this issue Feb 25, 2021 · 4 comments
Closed

Multi-day date filter in sessions #3471

macobo opened this issue Feb 25, 2021 · 4 comments
Labels

Comments

@macobo
Copy link
Contributor

macobo commented Feb 25, 2021

Is your feature request related to a problem?

Currently in sessions you need to select a date to filter by. This can be annoying if searching for a specific session (via filtering)

Describe the solution you'd like

Have a dropdown instead, with the default being "Last 30 days".

Describe alternatives you've considered

Additional context

The original reason for this limitation was performance - implementing this should also involve checking whether it continues working in all conditions.

Thank you for your feature request – we love each and every one!

@macobo macobo changed the title Non-day based date filters in sessions Multi-day date filter in sessions Feb 25, 2021
@paolodamico
Copy link
Contributor

+1 on this! This is my single biggest pain point too when watching session recordings. Using our default timeframe dropdown should be the best approach here as you mention. Related but not part of this issue, we do need to improve the UX of that filter (as detailed in the relevant issue).

@macobo
Copy link
Contributor Author

macobo commented Aug 23, 2021

Some context on this:

This has two distinct components:

  1. Performance - current implementation of this will fail on larger clickhouse and postgres teams due to the amount of data processed. Optimizing this is also tricky, multi-day work at minimum.
  2. Design - we need a proper multi-day search filter (dropdown) designed. cc @clarkus

Given that the solutions arrived at #4884 simplify the logic a lot making the performance issues go away, I'd suggest not working on this until then but bundling this into that project.

@clarkus
Copy link
Contributor

clarkus commented Aug 23, 2021

Related #2779

@paolodamico
Copy link
Contributor

Based on the resolution for #4884 (PostHog/posthog.com#2028), we can now close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants