Skip to content
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

Closed
wants to merge 77 commits into from
Closed

Filters #890

wants to merge 77 commits into from

Conversation

MoshiKoi
Copy link
Member

Proof of concept, looking for feedback

@cellio
Copy link
Member

cellio commented Sep 13, 2022

Addresses #755 .

app/controllers/users_controller.rb Outdated Show resolved Hide resolved
app/models/filter.rb Outdated Show resolved Hide resolved
MoshiKoi and others added 2 commits September 14, 2022 10:00
Co-authored-by: ArtOfCode <ArtOfCode-@users.noreply.github.com>
@cellio
Copy link
Member

cellio commented Nov 18, 2022

@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?

Copy link
Contributor

@Taeir Taeir left a 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
Copy link
Contributor

@Taeir Taeir Nov 24, 2022

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.

Copy link
Member Author

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.

t.string "tags_cache"

@@ -0,0 +1,6 @@
class DiallowFilterUserOrNameNull < ActiveRecord::Migration[7.0]
def change
change_column_null :filters, :user_id, false
Copy link
Contributor

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.

Copy link
Member Author

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).

config/config/preferences.yml Show resolved Hide resolved
db/seeds/filters.yml Show resolved Hide resolved
test/fixtures/category_filter_defaults.yml Outdated Show resolved Hide resolved
render json: { status: 'success', success: true, name: default_filter&.name },
status: 200
else
render json: { status: 'failed', success: false },
Copy link
Contributor

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?

app/views/search/_filters.html.erb Show resolved Hide resolved
<%= 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>
Copy link
Contributor

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"?

Copy link
Member Author

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

Copy link
Member

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. :-) )

Copy link
Member Author

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™️

app/models/filter.rb Show resolved Hide resolved
test/fixtures/filters.yml Outdated Show resolved Hide resolved
app/assets/javascripts/filters.js Outdated Show resolved Hide resolved
app/assets/javascripts/filters.js Show resolved Hide resolved
app/assets/javascripts/qpixel_api.js Outdated Show resolved Hide resolved
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],
Copy link
Member

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?
Copy link
Member

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"

Comment on lines +31 to +39
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
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

test/fixtures/filters.yml Outdated Show resolved Hide resolved
@@ -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'
Copy link
Contributor

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.

Copy link
Member Author

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.

MoshiKoi and others added 2 commits December 20, 2022 14:50
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
Co-authored-by: Taico Aerts <devtaeir@taico.nl>
@MoshiKoi
Copy link
Member Author

This test no longer succeeds due to a change in how search works:

test 'get without a search term should result in nil' do
get :search
assert_response 200
assert_nil assigns(:posts)
end

Now, an empty search will return all posts. Should this method be changed to instead assert not nil?

@MoshiKoi
Copy link
Member Author

Since it was easy, I just added in #905 as well.

@Taeir Taeir mentioned this pull request Jan 21, 2023
@MoshiKoi
Copy link
Member Author

Work is continuing on #976

@MoshiKoi MoshiKoi closed this Jan 25, 2023
@MoshiKoi MoshiKoi deleted the filters branch June 27, 2023 03:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants