-
Notifications
You must be signed in to change notification settings - Fork 26
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
[SHARED DEV] [#162198] Add filters to Projects tab #4368
Conversation
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.
Looks good, left a few comments/requests
Projects::Project | ||
.joins(:orders) | ||
.where(orders: { facility_id: @current_facility_id }) |
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 we have a scope that does this same thing:
Projects::Project | |
.joins(:orders) | |
.where(orders: { facility_id: @current_facility_id }) | |
Projects::Project.for_facility(@current_facility_id ) |
... but isn't this logic going to include single facility projects as well?
for OrderDetail we have this scope:
scope :cross_core, lambda {
joins(order: [:facility, :cross_core_project])
.where.not(orders: { cross_core_project_id: nil })
}
... can you add something like that to the Project model?
then we can do:
Projects::Project.cross_core.for_facility(@current_facility_id )
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.
Oh, you're right! I added a case for specs but those single facility projects don't have any orders attached.
end | ||
|
||
def single_facility_projects | ||
Projects::Project |
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.
Projects::Project | |
Projects::Project.single_facility.for_facility(@current_facility_id ) |
...
scope :single_facility, lambda {
joins(order: [:facility, :cross_core_project])
.where(orders: { cross_core_project_id: nil })
}
|
||
search_params = params[searcher_class.key.to_sym] | ||
|
||
# Options should not be restricted, they should search over the full order details |
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.
# Options should not be restricted, they should search over the full order details | |
# Options should not be restricted, they should search over the full list of projects |
@@ -83,6 +88,10 @@ def showing_inactive? | |||
|
|||
private | |||
|
|||
def initial_projects | |||
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.
Any reason to use nil
here instead of an empty array? curious why this needs a method of its own? maybe the searcher should have this as an optional input?
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 searcher uses recursion to filter the previous list of projects, making the input optional would also mean switching the params. I can do that but I wonder if it's the best as it'd make this searcher different from the rest and could be a bit confusing.
It definitely doesn't need to be its own method, I'll fix that.
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.
🎉
Release Notes
Screenshot
When there are results
When there are no results
Additional Context
Accessibility