36d795f69c
As mentioned in commitbc0f04075, a <select> field which submits its form on change causes many accessibility and usability issues. In this case there was also an incompatibility with the advanced search filter which caused a bug solved in commit541a5fa89. So the question is where to position the filters and how to display them. One factor to take into the account is how relevant these filters are, particularly compared to the links to select the prefered order, since we don't usually give users the choice of both filters and orders. Our filters don't really make sense until the valuation phase starts, since before that phase investments aren't selected nor their feasibility is decided. After that phase, the only phase where citizens are really involved is the final voting; the rest of the phases are done by valuators and administrators. In the final voting, citizens can only vote on selected projects, and that's the default filter during that phase. So these filters are mainly there for information purposes, and not to help citizens in the phases where they're actually involved (accepting projects, selecting projects and balloting). Orders, on the other hand, play a crucial role during the final voting phase. Since citizens might have already voted for a few projects and have, let's say, 100,000€ left, ordering by price allows them to find which projects are within their remaining budget. In conclusion, orders are more important than filters, and so they should have a more prominent place. For consistency with the proposals section, where we've got some links in the sidebar (bottom part of the page on small screens) providing a similar funcionality, like accessing selected proposals or archived or retired proposals, we're moving the investments filters to the sidebar (bottom part of the page on small screens) as well.
58 lines
1.4 KiB
Ruby
58 lines
1.4 KiB
Ruby
module Search
|
|
extend ActiveSupport::Concern
|
|
|
|
included do
|
|
before_action :parse_search_terms, only: [:index, :suggest]
|
|
before_action :parse_advanced_search_terms, only: :index
|
|
before_action :set_search_order, only: :index
|
|
end
|
|
|
|
def parse_search_terms
|
|
@search_terms = params[:search] if params[:search].present?
|
|
end
|
|
|
|
def parse_advanced_search_terms
|
|
@advanced_search_terms = params[:advanced_search] if params[:advanced_search].present?
|
|
parse_search_date
|
|
end
|
|
|
|
def parse_search_date
|
|
return unless search_by_date?
|
|
|
|
params[:advanced_search][:date_range] = search_date_range
|
|
end
|
|
|
|
def search_by_date?
|
|
params[:advanced_search] && params[:advanced_search][:date_min].present?
|
|
end
|
|
|
|
def search_start_date
|
|
case params[:advanced_search][:date_min]
|
|
when "1"
|
|
24.hours.ago
|
|
when "2"
|
|
1.week.ago
|
|
when "3"
|
|
1.month.ago
|
|
when "4"
|
|
1.year.ago
|
|
else
|
|
Date.parse(params[:advanced_search][:date_min]) rescue 100.years.ago
|
|
end
|
|
end
|
|
|
|
def search_finish_date
|
|
(params[:advanced_search][:date_max].to_date rescue Date.current) || Date.current
|
|
end
|
|
|
|
def search_date_range
|
|
[100.years.ago, search_start_date].max.beginning_of_day..[search_finish_date, Date.current].min.end_of_day
|
|
end
|
|
|
|
def set_search_order
|
|
if params[:search].present? && params[:order].blank?
|
|
params[:order] = "relevance"
|
|
end
|
|
end
|
|
end
|