Custom Filter Documentation

[pascalbetz]

The doc at https://www.reportskit.co/examples/filter_boolean mentions followiung config for the custom filter:

measure:
  key: post
  name: Published Posts
filters:
- key: is_published
  criteria:
    value: true
dimensions:
- author

Is the criteria required? I don't think so since the custom filter does not take any argument?

[tombenner]

In this case, criteria is indeed required, but this may not be the most intuitive design (see Possible Solution below). Currently, when a filter is listed in filters, it only means that it will only be applied if filter criteria is provided (either in the configuration or from a form filter, like a checkbox). If the criteria is blank, then the filter won't be applied, similar to how form filters usually work.

Part of the motivation for this is to allow users to whitelist filters that can be used by form filters. For example, if the following YAML is used, then it means that a checkbox can be used to optionally enable the is_published filter:

measure:
  key: post
  name: Published Posts
filters:
- key: is_published
dimensions:
- author

If we changed this behavior, such that above YAML meant that is_published is always enabled, then the is_published checkbox wouldn't do anything.

Possible Solution

I think the confusion here is due to is_published being defined as a boolean filter, even though it's more of a scope without arguments (it's not really a boolean filter, as it doesn't support true/false values). One solution might be to define a new type of filter called a scope:

class Post < ApplicationRecord
  include ReportsKit::Model
  reports_kit do
    filter :is_published, :scope, conditions: ->(relation) { relation.where(status: 'published') }
  end
end

This would have the following behavior:

• Scopes cannot be used as interactive form filters (e.g. checkboxes)
• Scopes are enabled whenever they are listed in the report configuration
• Scopes do not support criteria (we could support this in the future, but most use cases don't require it)

In my own use of ReportsKit, I've noticed a lot of this kind of odd use of boolean filters when a scope would be more appropriate, so this seems like a common problem, and the above solution would work well for my use cases, at least.

This would also open the door for us to more concisely use existing ActiveRecord scopes (perhaps without configuring a ReportsKit scope), but we may want to defer that until after we have this more general problem solved.

Thoughts?

[pascalbetz]

Thanks for the explanation. I'm not sure I understand I fully understand all the possible use cases as I am just tinkering with reports_kit currently. Here are my two cents anyway, in no particular order:

Support for scopes (besides through context object) would be cool, IMHO. Scopes should be able to take parameters through the config. When scopes take multiple parameters it might be a bit tricky to build a form for them.

I find the configuration of filters to be somewhat overloaded and there are multiple allowed variants. It looks like this is valid as well?:

filters:
- is_published

About the filters and forms: I think this does impose a security issue if a user can disable filters by modifying the request that is being sent to the server? If so, then this behavior should be disabled by default!

I don't mind verbosity when it adds clarity. So how about a config format that is explicit (i.e. a key to enable filters for forms)