I want to be able to create default filters in my Explores

Description: What is it?

I want to add default filters to my Explores so that when people use them, they automatically have filters applied to them.

These filters are either:

• empty, but the field is filtered to an empty value so users are pushed to filter on that field
• filled with one or many values

Problem: What problem does this solve?

Some datasets are really large or require specific filters to “make sense”. For example, if I wanted a Sales explore, but only for my EMEA team, I’d want to filter my sales explore to EMEA by default in their project.

Another example from a user: we are dealing with a massive amount of data partioned by date. We would like to force a filter on the date in order to force the user to apply a date. It will first avoid to have an error because you can not query a partioned table without a where condition on the date

What: Roughly, what does this look like in the product?

• users can apply filters to Explores in their dbt projects.
• The filters are applied on a model level (i.e. under model -->meta --> filters)
• the filter syntax is the same as what’s used here: https://github.com/lightdash/lightdash/issues/3126
• there are three types of filters:
  • default filters are applied to the table, but can be overridden in the UI (the same way as dashboard saved filters can be overriden, for example).
  • required filters can have their values changed, but cannot be removed from the filters list in the UI
  • sql_where filters cannot be changed and cannot be removed - these are actually hidden from the user in the UI. They’d only be visible in the compiled SQL.
• if we need to reduce scope or break this up, we can just make default filter types to begin with, then open new issues for building the other two types

models:
  name: users
  meta:
    filters:
      - filter: ${created_at_date} # this should match the field. You can also filter on joined fields.
          sql: >= '2022-05-21' # required
          type: default # the default value for type is 'default'

[owlas]

If we want this to be fully compatible with the UI we have for filtering and interact well with dashboard filters + explore filters, the structure of the filters will need to be the same.

So instead of:

    filters:
      - filter: ${created_at_date} # this should match the field. You can also filter on joined fields.
          sql: >= '2022-05-21' # required
          type: default # the default value for type is 'default'

It would be more like:

target:
  fieldId: created_at_date  # not sure if this should be referenced with ${}
operator: "inThePast"
values: [5]
settings:
  unitOfTime: "years"
  completed: false

^ this is obviously pretty annoying to write and we could figure out a simplified structure. But we need the filters to be compatible with this layout.

---

type: default|required

Instead of type could we have a field isEditable: true|false or isRequired: true|false seems more intentional

[TuringLovesDeathMetal]

1. Yes! this feels like the last piece for the three filter types: a. Default filter: can change, can be removed b. required filter: can change, but cannot be removed c. sql_where: cannot change, cannot be removed (hidden from the user)

2. Yes, the value can change and it can be removed entirely.

3. It cannot be removed (you have to add at least one filter on this value) - I’m not sure if the value should be able to be changed or not 🤔 I’m leaning towards “yes”