Describe the bug
In the past we migrated from searchlight to ransack for the participant side searches (see #8748).
This makes total sense because we were already using ransack in the admin panel and we wanted to get rid of dependencies that serve a similar purpose.
One issue with ransack is that it allows searching with any parameters. We limit those parameters using our own logic within this method:
|
def filter_params |
|
@filter_params = begin |
|
passed_params = params.to_unsafe_h[:filter].try(:symbolize_keys) || {} |
|
passed_params.transform_values! { |value| value == all_value ? nil : value } if all_value.present? |
|
default_filter_params.merge(passed_params.slice(*default_filter_params.keys)) |
|
end |
|
end |
Ransack enforces defining ransackable_attributles in version 4.0.0 through this PR:
activerecord-hackery/ransack#1400
We should eventually also limit the attributes that ransack is able to receive to the desired ones in all searches to avoid any oversights regarding this.
To Reproduce
You can try Ransack filtering from the console, e.g. filter proposals or meetings with some attributes using the Ransack API:
https://activerecord-hackery.github.io/ransack/
You will notice that it allows filtering with any attributes.
In the UI, we are however limiting the permitted filtering paramters but we should also utilize the new Ransack API provided by version 4.
Expected behavior
For all searchable/"ransackable" records, we should limit the available searching parameters using ransackable_attributes.
This is further explained at:
https://activerecord-hackery.github.io/ransack/going-further/other-notes/#authorization-allowlistingdenylisting
Extra data
- Device:
- Device OS:
- Browser:
- Decidim Version:
develop
- Decidim installation:
Additional context
By implementing the ransackable_attributes across the different records, we could potentially also simplify some of the code that we currently have for filtering the records.
Describe the bug
In the past we migrated from
searchlighttoransackfor the participant side searches (see #8748).This makes total sense because we were already using
ransackin the admin panel and we wanted to get rid of dependencies that serve a similar purpose.One issue with ransack is that it allows searching with any parameters. We limit those parameters using our own logic within this method:
decidim/decidim-core/app/controllers/concerns/decidim/filter_resource.rb
Lines 52 to 58 in a8c5265
Ransack enforces defining
ransackable_attributlesin version 4.0.0 through this PR:activerecord-hackery/ransack#1400
We should eventually also limit the attributes that ransack is able to receive to the desired ones in all searches to avoid any oversights regarding this.
To Reproduce
You can try Ransack filtering from the console, e.g. filter proposals or meetings with some attributes using the Ransack API:
https://activerecord-hackery.github.io/ransack/
You will notice that it allows filtering with any attributes.
In the UI, we are however limiting the permitted filtering paramters but we should also utilize the new Ransack API provided by version 4.
Expected behavior
For all searchable/"ransackable" records, we should limit the available searching parameters using
ransackable_attributes.This is further explained at:
https://activerecord-hackery.github.io/ransack/going-further/other-notes/#authorization-allowlistingdenylisting
Extra data
developAdditional context
By implementing the
ransackable_attributesacross the different records, we could potentially also simplify some of the code that we currently have for filtering the records.