Advanced User Controls and Proper Path Validation

[neilkakkar]

Changes

Fixes #6041 <- more context about the solution there. I haven't heard any strong opposition yet, so went ahead with the approach.

This PR:

1. Introduces advanced Path manipulation options. I'm putting these on the old UI right now (as I myself want to test what happens with these & iterate). Looking for some quick feedback, if it's okay as is, or needs to be behind a FF / needs an Advanced Options section. (cc: @clarkus , @paolodamico )

2. On the backend, introduce the Path manipulation operators: Min and max edge weights, plus total edge count.

3. Validates the paths graph returned from the query, removing all dangling edges. I decided for now to do this in all cases except when Min or Max edge weight is defined (kinda open question if we want to do this here as well). See test_path_min_edge_weight for why it makes sense to not do this here. When min weight is defined, it's very much possible that the initial edges will be removed, and then removing the dangling edges destroys the graph, which we probably don't want to happen.

Thoughts welcome!

Checklist

• All querysets/queries filter by Organization, by Team, and by User
• Django backend tests
• Jest frontend tests
• Cypress end-to-end tests
• Migrations are safe to run at scale (e.g. PostHog Cloud) – present proof if not obvious
• New/changed UI is decent on smartphones (viewport width around 360px)

[paolodamico]

Tested the functionality (i.e. didn't reviewed the code), in general lgtm.

• UX-wise I made a comment in the relevant issue about whether we can simplify and only give the option to users to specify a min edge weight (no max).
• I think we should put these controls under an "Advanced" toggle. CC @clarkus for thoughts.
• UI needs to be updated too based on latest designs.
• Also made a comment in the original issue, but it's not super clear where the weight is calculated (probably a misunderstanding on my end). See this path where start and end nodes have 5 users, but the max is set at 3.
  

[neilkakkar]

UI needs to be updated too based on latest designs.

I wanted to put this on the old UI as well for now, so I can myself play with these options and see how they work. Very hard / not worth the effort - to do it outside the app 😅.

---

re: weights, answered in the issue. But yeah, the idea is that weight is between two path items, not the total from start to end. So, in the above image, it's the count on each of the blue bars, not the count on the grey bars.

[paolodamico]

Continuing conversation in main issue

[EDsCODE]

1. Definitely put behind a feature flag
2. I think the weighting is a clever solution but we should test ourselves behind feature flag to see if it makes sense as a UX. Because I think at a certain point you might just be guessing parameters
3. Seems like you can run into the dangling
4. Suggestion: split of the validation/dangling path elimination into separate PR that we can merge immediately. Then work on the weight setting and UI after we get in the new UIs New paths tab querybuilder UI #5825 New paths UI sankey card #6066

[neilkakkar]

3. Seems like you can run into the dangling

Wut?

[neilkakkar]

(2) is exactly why I wanted to put this on the old UI, so I could test it myself.

But, I guess it's okay to do this after we have the new UI. Split out part of the solution: The deletion of dangling edges - into a separate PR.

[neilkakkar]

Closing in favour of: #6173