-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Spike of community resource browsing #980
Conversation
there are still a lot of problems with them
The community resources were being filtered out because they don't use service areas the same way as asks and offers. This refactors the scope stuff for filtering by service areas so that it works for community resources as well as asks and offers Co-authored-by: connieh1 <connie2630a@gmail.com>
6a55169
to
7ce313f
Compare
7ce313f
to
f888f85
Compare
# TODO: This is a hack that makes things work for now | ||
# The test creates a contact method that will match this | ||
# and the dev db seeding creates a couple, too | ||
ContactMethod.method_name('call').last |
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.
Is there some way I can fix this in its own PR? In other codebases I work in, this whole workflow is something I'd hide behind a feature flag so I can get this PR out first, and then get the contact methods for community resources working in a separate PR. I could also try to fix it here, especially if anyone's willing to help me with it. Please let me know
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.
Added an issue for this at #986
a3eb745
to
9c7f9ae
Compare
def type | ||
"Community Resource" | ||
end | ||
|
||
def inexhaustible | ||
true | ||
end | ||
|
||
def urgency_level_id | ||
UrgencyLevel::TYPES.last.id | ||
end |
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.
@exbinary mentioned that these don't feel like actual attributes, behaviors, or properties of a community resource, and so they might be better off in an abstraction or interface class that turns community resources into something blueprint-able
"description" => "Food for the revolution", | ||
"inexhaustible" => true, | ||
"location" => nil, | ||
"match_path" => nil, | ||
"name" => "Free breakfast for School Children Program", | ||
"person" => 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.
@exbinary pointed out how hashes like this to test blobs of JSON are fragile since small changes can then require lots of edits
This requires a service area and category for every saved community resource Cons: * makes our code less flexible, more brittle because it hardens dependencies between the models * may frustrate users (but honestly, we don't know without finding some users and asking them) Pros: * easy to remove if we change our mind (harder to add later once invalid data already exists) * very little code to implement and maintain * requires less rethinking of assumptions for Map and List browser Vue code
# We're not sure if we need or want these validations. Adding them now assuming it will be easier to remove them later than the other way around | ||
validates :service_areas, presence: true | ||
validates_associated :service_areas | ||
validates :tag_list, presence: true |
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.
- TODO: fix request specs that now flunk validation checks
d03455d
to
e898c66
Compare
also destroy relevant join table records when destroying a community resource
e898c66
to
cd5aa11
Compare
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 good to ship, right @h-m-m ? I know there are caveats that you've documented but otherwise LGTM. Woohoo! 🚀 .
Conflicts: * app/javascript/pages/browse/MapBrowser.vue
The introduction of community resources to /contributions means that `.id` is not guaranteed to be unique across all types.
Why
This addresses some of #882 and #880. Specifically, it
What
This updates our filtering classes so they can handle community resources.
The contact method logic is not implemented correctly, see inline notes below
There are certainly other aspects of this which are incomplete
How
Testing
Next Steps
Outstanding Questions, Concerns and Other Notes
Accessibility
Security
Meta
Pre-Merge Checklist