hurricane-response / florence-api Goto Github PK

We have just been pushing to master but at some point version and tags might be a good idea. Any thoughts on when/where to start?

Just noticed this post-merge. @omnilord would be good to get a fix quickly before we deploy.

In the archived screens, the table still points to "Show/Update" instead of "Show/Unarchive".

Also, in the detail screen, at the top, it still has an "ARCHIVE" link, which really should be "UNARCHIVE" when it's already archived.

@nihonjinrxs made an excellent observation that we don't have distribution points included in the api:import function and should add it.

Relevant files:

• import.rake
• api_importer.rb
• New import job required (see import job scripts in app/jobs)

I haven't investigated the schema to know if it would better to just add a new flag or create a whole new object.

cc @GovInTrenches

From what I can tell, you have to edit a shelter in order to close it. Seems a checkbox or multi-check would help facilitate that as threat shifts or dissipates.

Expected behavior for the search bar would be to return any text that matches query (For example, Pittsboro) - instead it only returns county names.

We need the search bar to search at the very least name, address, county

Hurricanes? What about tornados? Earthquakes? Fires? Floods? Droughts?

So far, proposals have included:

• Single domain for API, but separate event-specific domains for front ends
• Single domain for all, with subdomains for API and each event's front end
• Single base domain, but heavily namespaced base URLs for API and event front ends

What are we doing here?

From /shelters/outdated if you click the "mark current" link, it redirects back to /shelters

Expected Behavior
When fetching data from the the API the shelter objects should supply consistent formats for it's property values.

eg

[
     {
        "address": "123 example way",
        "city": "Exampleton"
    },
    { 
        "address": "456 foo st.",
        "city": "Barberg"
    },
   ...
]

Current Behavior

I am receiving different formats for the address values, some contain just the street address and some contain the street, city, state and zip.

Note:
I am setting conditionals for the different formats and for just types it's not too bad.

json.cache! is not currently set to expire in several files. Ensure that caching expires if caching is enabled.

See:
https://github.com/hurricane-response/florence-api/blob/master/app/views/api/v1/shelters/index.json.jbuilder
https://github.com/hurricane-response/florence-api/blob/master/app/views/api/v1/shelters/outdated.json.jbuilder

Other files may be using this as well.

afaik the only way to mark a shelter updated is to manually edit a field. When checking statuses, it might be handy to have a checkbox or some other way of updating a shelter/POD without editing a field.

Something like /api/v1/shelters/outdated or /api/v1/shelters?outdated=true

Converting the Postgres enum types to string and using ActiveRecord string enums will alleviate some friction over differing local postgres installs for developers not using Docker or Postgres 9.6 locally.

if a POD is de-activated, there is no UI to resurface that location.

dependencies are out of date, getting vulnerability warnings from GitHub, notes in Heroku build logs "the running version of Bundler (1.15.2) is older than the version that created the lockfile (1.15.4)"

phone is currently a required field, but not provided by FEMA

Mapbox GL ingests geojson nicely to allow more dynamic filtering and layering.

If we had second API endpoints our mapipng options would open up.

I understand this is a longer term goal and needs more discussion but opening it up now after a day of reading the docs.

Now that we have data from Irma, Florence and Michael it would a good idea to have a backup of the database. I'm not sure the options for doing that on Heroku, but an offsite backup would be good too.

e.g. https://www.google.com/maps/d/u/0/viewer?mid=1FQti1xtzPgBu09WrvwMKlic5gwLgeKtL&ll=34.382028808154644%2C-78.8599227863478&z=8

Allow volunteers to request a set of shelters(phone) to update. Once they get their list, the numbers are taken off the stack. Update made - number released. No update made after 5 or 10 minutes, return to needs updating stack.

After a discussion tonight at Code for Tampa Bay meetup wanted to document a thought.

I don't have a specific use case in mind, but I know it's been discussed in the past as well. We should document the current way updates are approved. I'm not 100% sure the system now. My recollection is shelter updates were in real time between a super admin and other volunteers where a quick level of trust was built. Insert something about scale here.

Currently I do not see an admin UI to delete a shelter. Only archive. Not sure what original design decision on that was.

On Line 32 of the filter_by_params concern, the :near parameter is unused but is required for filtering by geocoordinates. I believe the intent was to pass an optional numeric value to the #near function on Line 35.

From Danny McGlashing (who coordinated this effort on Harvey & Maria):
"Key questions for shelters we asked were:

• How many beds do you have available?
• How many for men, for women and for children.
• Do you need evac - are you being flooded?"

We should review the documentation to make sure that if we're making it readable for non-technical staff. Specifically, if a member of FEMA or other disaster organization reads this, it should be clear what this actually does in plain English.

We should also keep in mind that they'll be other Code for All partners around the world that might be looking at this too and so our docs need to be super-readable

If we are unable to reach a shelter by phone consistently, caller volunteers should be able to mark this in the API so that others can flag for FEMA or search for a better number.

Future project: someone clicks an "i want to make one phone call" button and it gives them a number, a script, and a form to fill out the update showing old value, and new value ____ for each field. Updating logistics have been the biggest challenge 3 storms in a row now, not really maps or anything... and i say this as a guy who made a map.

It'd be good to be able to sort by multiple columns in a specific order of preference. That would make it easier to find shelters in the right locations (most important) that would be easiest to call (useful if you're short on time) and are most out of date.

At https://api.hurricane-response.org/shelters/outdated you can select multiple columns to sort by, but you can't unselect any columns once you select them.

Refreshing the page (even without cache) doesn't unselect the columns.

[This isn't a problem at https://api.hurricane-response.org/shelters]

Browser: Chrome v75.0.3770.142

This is somehow related to the default_scope hiding the archives from the deduplication function, but I'm not sure how since the deduplication function unscopes the default_scope.

Ideal solution: if a record exists and is archive, unarchive instead of inserting a duplicate.

(also, the duplication counter in the third query (source) is not guaranteed to be unique).

This entails several things:

• Close #74 by answering naming questions
• Creation of a new table and model to store disaster events and info
• Creation of association tables between shelters, distribution points, etc. and disaster events and associated model updates
• Views in the admin screens to add/update/archive disaster event records
• Update of API endpoints to require disaster event filtering
• Removal of references to specific storms in naming within the app (i.e. repo name, db info, etc.)
• Redeploy of new clean instance with generic naming
• Repopulation of data from old instance, and population of association tables as needed for existing data
• Repointing of front end apps to new instance with appropriate filtering
• Decommission of old production instance

We now have a new instance running on https://api.hurricane-repsonse.org from this repository.

I know there are still references to Harvey in the API but other than possibly breaking check outs and automated tools (important!) I'm not aware of any other negative effects of renaming, but would help clarify that this is the main on-going repository and not related to a 2018 storm.

https://drive.google.com/file/d/0B4swUlBpdMTMQ25jYVZnSW1ZWG8/view <- this was a great guide; we should take it and update the site to show better instructions including a calling script

CEDR is a partner, we should have their logo on the website

It'd make it easier for people trying to update shelters if they didn't have to search for which shelters are currently relevant. If there could be a way for admins to select specific states or geographic areas, there might be a way to let people more easily find those shelters.

Currently the code base has a lot of custom rubocop configuration as documentation of the styles most commonly used in the source code, not necessarily the best options moving forward. While the code is mostly uniform currently, these cops should be reviewed for further revision/refactoring to ensure our code base is adequately constructed.

currently if you want to edit an archived shelter, you can't also update and archive in a single click.

Also, when unarchiving a shelter from the archived shelter page, it redirects back to the shelter page, not the same page you were on.

If we have a shelter added that we don't have information - this defaults to 'false' - when we go to update it - it then enters a zero which the API reads as true.

We need to put in something that shows a N/A and display that status on the map until we confirm otherwise.

It was brought up that having a Dockerfile (or vagrant setup) would help new collaborators jump in and start working on solving issues without having to retool their local environment.

Originally posted by @miklb in #79 (comment)

In discussion about style guide for the map site, @tdooner brought this CFA styleguide to my attention and wonder if it might make a better admin UI for the API backend/call center.

Probably a good idea to keep as up-to-date as possible on dependencies while we're not in midst of hurricane season.

• Update to latest ruby (currently 2.6.0, released Dec 25, 2018)
• Update to latest rails (currently 5.2.2, released Dec 4, 2018)
• Update other dependencies as appropriate

The "Special Needs" checkbox currently in the shelter API is confusing, because what does "yes" mean given the wide range of special needs?

Instead, we should have a text field similar to "Pets" labeled "Accessibility".

Helper text can be:
"Wheelchair accessible, or other accommodations for people with special needs?"

(LOWER PRIORITY - POST EVENT)

The Red Cross uses a National Shelter System that's fairly common - however the data standard is fairly huge. I don't know if there's a way to make the API 100% compliant but where we can we should try to match the standard.

Here's the guide https://nss.communityos.org/local/os125/posting_area//documents/NSS%20Documents%20v%203.1/NSS_UserGuide.pdf

In my local environment and on Heroku it doesn't appear the geocoder is running with fema:import.

Right now it's not a show stopper as we won't be doing a lot of import tasks, but worth noting for future development.

Right now, there's column area for states but there's not a way to update it. It would be useful to do this since we have multiple states we're looking at

Lots of remaining references to harvey-api in the dev getting started section of the README.

I can try to tackle this first thing in the morning.

For the current deploy, are you all still using the harvey-api account names, or have you changed them?