[GitHub] [superset] villebro commented on issue #13943: Filters should be considered handled when jinja templates uses them

[GitBox <gi...@apache.org>]

villebro commented on issue #13943:
URL: https://github.com/apache/superset/issues/13943#issuecomment-824858408


   I think there are two solutions to this. One is to collect "used" filters as proposed here, much like how `cache_key_wrapper` does. If we decide to do that I'd almost recommend adding it as an optional argument to the `filter_values` hook, something like `filter_values('full_name', remove_filter=True)`, after which the filter is removed from the filter list.
   
   Another approach would be to make it possible to emit selected values as key-value pairs into `custom_form_data` in `ExtraFormData`, and then add a function to the Jinja context that can pick those up. This way they wouldn't interfere with regular filters. In the above case, the Pie chart would call the `setDataMask` hook with something like
   ```
   {
     custom_form_data: {
       employees: ['Employee 1', 'Employee 2']
     },
   }
   ```
   after which we could pick those up in Jinja, something like
   ```
    {{ "'" + "', '".join(custom_form_data_values('employees')) + "'" }} 
   ```
   I'd personally vote for the latter approach, as removing filters could have security implications, especially for deployments utilizing RLS or other similar means of automated data filtering.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org