-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filters #890
Filters #890
Conversation
Addresses #755 . |
Co-authored-by: ArtOfCode <ArtOfCode-@users.noreply.github.com>
@ArtOfCode- , Moshi said in chat that this is ready for an initial code review. I see there are merge conflicts which obviously have to be resolved, but can someone can take a look at the code for any other issues in the meantime? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is some quite great work @MoshiKoi ! There are quite a few annoying/tricky cases in the search (and other places) that you dealt with in a pretty nice way :)
I do have quite a few review comments, some of those questions about the workings, others small improvements or suggestions. For a final version, I also think we should write some tests, to verify that basic filters work as intended.
I have not yet checked your JavaScript code, I kept to the Ruby and HTML for now. I will take a look at that at a later time if I get to it.
@@ -0,0 +1,6 @@ | |||
class AddTagsToFilters < ActiveRecord::Migration[7.0] | |||
def change | |||
add_column :filters, :include_tags, :string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a string column these would have a max length of 255 characters, which may not be sufficient. We could change it to text or switch how include_tags and exclude_tags are stored from array to something else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same way that tags are stored on posts and it seems to be doing okay - I don't imagine someone is going to be filtering by more tags than can fit on a post, but I could be wrong.
Line 411 in ad595c3
t.string "tags_cache" |
@@ -0,0 +1,6 @@ | |||
class DiallowFilterUserOrNameNull < ActiveRecord::Migration[7.0] | |||
def change | |||
change_column_null :filters, :user_id, false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first three migrations can be merged into one to directly create the right table setup/structure. Depending on the underlying database, this could be slightly beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't actually know how to do this, so I'll leave it to you (or someone else).
render json: { status: 'success', success: true, name: default_filter&.name }, | ||
status: 200 | ||
else | ||
render json: { status: 'failed', success: false }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be an error message here?
<%= submit_tag 'Apply', class: 'button is-medium is-outlined', name: nil %> | ||
<% end %> | ||
<% if user_signed_in? %> | ||
<button type="button" class="filter-save button is-medium is-filled">Save</button> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we display the button but grayed out (disabled) and with a title set to indicate "this is not possible because you are not signed in"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure - I personally prefer it the way it is now, but I'm open to changing it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the current behavior? (She says, hoping to avoid having to pull and set it up locally to find out. :-) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just Not There™️
if user_signed_in? && params[:name] | ||
filter = Filter.find_or_create_by(user: current_user, name: params[:name]) | ||
|
||
filter.update(min_score: params[:min_score], max_score: params[:max_score], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No obvious security risks that I can see here, but the validation concerns are... valid (ha!). Worth considering strong params here, i.e. filter.update(permitted_params)
, where permitted_params
is a method that calls params.require(...).permit(...)
etc.
include_tags: params[:include_tags], exclude_tags: params[:exclude_tags], | ||
status: params[:status]) | ||
|
||
unless params[:category].nil? || params[:is_default].nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one might be more down to personal preference? I like an unless statement in Ruby - I find they make sense if you read them in natural language to yourself.
"Unless params[:category] is nil or params[:is_default] is nil"
vs
"If params[:category] is not nil and params[:is_default] is not nil"
qualifiers = [] | ||
qualifiers.append({ param: :score, operator: '>=', value: filter.min_score }) unless filter.min_score.nil? | ||
qualifiers.append({ param: :score, operator: '<=', value: filter.max_score }) unless filter.max_score.nil? | ||
qualifiers.append({ param: :answers, operator: '>=', value: filter.min_answers }) unless filter.min_answers.nil? | ||
qualifiers.append({ param: :answers, operator: '<=', value: filter.max_answers }) unless filter.max_answers.nil? | ||
qualifiers.append({ param: :include_tags, tag_ids: filter.include_tags }) unless filter.include_tags.nil? | ||
qualifiers.append({ param: :exclude_tags, tag_ids: filter.exclude_tags }) unless filter.exclude_tags.nil? | ||
qualifiers.append({ param: :status, value: filter.status }) unless filter.status.nil? | ||
qualifiers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider (quality): is it better to iterate through the properties of filter
and add to qualifiers
for each that exists, rather than repeated append/unless
statements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure how that would look to be honest; I'm not familiar enough with idiomatic Ruby patterns.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the treatment of each property is different, I see no good way to do what you propose.
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
@@ -24,6 +24,7 @@ class User < ApplicationRecord | |||
has_many :comments, dependent: :nullify | |||
has_many :comment_threads_deleted, class_name: 'CommentThread', foreign_key: :deleted_by_id, dependent: :nullify | |||
has_many :comment_threads_locked, class_name: 'CommentThread', foreign_key: :locked_by_id, dependent: :nullify | |||
has_many :filters, dependent: :destroy | |||
belongs_to :deleted_by, required: false, class_name: 'User' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On another note, the question is why category_filter_defaults is linked to user, since it is also linked to filter and filter is linked to a user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is the System filters. We could have, for instance
Filter(Positive, belongs to System)
CategoryFilterDefault(Moshi, Meta, Positive)
To be honest, attaching "universal" filters to System might not have been the brightest idea, since it leads to weird edge cases like this.
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
This test no longer succeeds due to a change in how search works: qpixel/test/controllers/search_controller_test.rb Lines 6 to 10 in 8f36e90
Now, an empty search will return all posts. Should this method be changed to instead assert not nil? |
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
Since it was easy, I just added in #905 as well. |
Work is continuing on #976 |
Proof of concept, looking for feedback