issue: I think we should introduce the concept of nested filters on the dashboard, instead of patching in has_not_done as an operator with the goal dimension.

While it certainly works in this case, it creates yet another difference between the FE representation of a filter and the BE representation.

Current differences at the filter level are manageable (I hope):

• dimension is shortened in the FE
• clauses are flattened

Other planned differences (debatable):

• filter modifiers are moved from last position to the position next to operation

It's a bunch of work, and how exactly it should look like in the UI is debatable, but I believe we should take this leap forward now, rather than later.

#4810 (comment)

how exactly it should look like in the UI is debatable

The intended UI is already nailed down - we don't want to be rebuilding the filters UI/UX for the sake of this change. AS such, the only effect of this refactor would be in the code rather than visible for the user.

The cost of doing it like this is potentially causing further issues when we rebuild the filters UI/UX, especially around doing redirects. This is a valid concern but given we already have experience around this and we already are doing filter transformations before sending requests to the API, I feel like the trade-off is reasonable.

Note there's a third alternative which would be introducing a has_not_done_goal internal operator in the backend. However this has it's own drawbacks in both validation (similar issue to segments) and us sometimes recommending users inspect query payloads to reproduce queries in APIv2.

In summary, we have 3 options:

Given these trade-offs I'm still partial to (1). How would you feel if I derisked option a bit by adding this context + documenting the prefixing logic to serializeApiFilters as documentation?

UI-wise, just to give some ugly visual aids to what I'm saying above

and group to be represented as an area with one or more filter pills in it, possibly collapsible

Of course, we might just decide that we want this released as is, as soon as possible, but it means in the future supporting one more special redirect scenario: where ?f=has_done,event:goal,Signup,Register must be recognized as a legal filter.

Ah, I was so focused on getting my message and visual aids across, I didn't notice the reply in between. Checking

In summary, we have 3 options: ...

Very nicely summarized. However, I'd like to see a bit more justification for option 1 besides less code right now. Where's the hurry with it? This feature would still be deployable and usable over the API while we bring the FE up to speed.

It seems to me that as soon as we want NOT or OR capability with filters, we'd have to embark on the nested filters support anyways.

Also, have you considered the cost over time of understanding and maintaining the various legacy systems that we have? Since they're going to be around for a long time (at the moment, I don't think we have any cutoffs planned), even a very small cost adds up. The more of these legacy nuances we have, the harder it will be to make progress.

A possible fourth option would be to keep the current patched-in UI, but implement support for nested filters in URL params and have the combobox apply it in its realistic nested format right away.

This feature would still be deployable and usable over the API while we bring the FE up to speed.

This would not be sufficient - the feature we're building here was to add this filtering capability to the dashboard.

It seems to me that as soon as we want NOT or OR capability with filters, we'd have to embark on the nested filters support anyways.

You are right, but we don't want to add that capability right now.

Adding advanced filtering capabilities is a whole project onto itself which needs careful consideration on UX side so we'd be able to both serve advanced users while not turning into Google Analytics query builder. We will likely embark on this journey at some point, but it needs a proper plan.

We discussed the UX of this feature with Uku on basecamp and on a call and decided exposing it as presented in this PR is a good compromise until we decide to tackle that.

Also, have you considered the cost over time of understanding and maintaining the various legacy systems that we have? Since they're going to be around for a long time (at the moment, I don't think we have any cutoffs planned), even a very small cost adds up. The more of these legacy nuances we have, the harder it will be to make progress.

I did consider it and given we don't know what form filtering will take in the UI long-term I don't see another option. Speculatively coding up a more complex solution will run into the same problem where where it will turn into legacy as soon as we discover the real requirements.

A possible fourth option would be to keep the current patched-in UI, but implement support for nested filters in URL params and have the combobox apply it in its realistic nested format right away.

The UX presented above is quite confusing - so we're trading off user experience in a core functionality for a speculative benefit down the line. That's a bad trade-off and not something we want to do.

I've added extra documentation + tests for serializeApiFilters in 2b2d4ee