Merge branch 'master' into snyk-upgrade-92ac3c9be4dca607ff38b5cfabcaa9e2

Author: stoopidJSON

.gitignore

@@ -113,4 +113,7 @@ dist
 .idea
 .terraform
 *.plan
-*.out
+*.out
+
+# MKDocs Wiki
+site/

CONTRIBUTING.md

@@ -1,76 +1,2 @@
 # Contributing
-When contributing to this repository, please first discuss the change you wish to make via issue,
-email, slack, or any other method with the contributes of this repository, or Code for Baltimore, before making a change. 
-
-Please note we have a [Code of Conduct](/docs/Code_of_Conduct.md), please follow it in all your interactions with the project.
-
-## Overview
-In the event of a disaster a municipality or state may have need to check in on the status of all healthcare providers, 
-or other types of entities, within in the jurisdiction. This system will provide methods for healthcare providers and 
-entities to check-in during disasters, and update their contact information during non-emergency periods. During an 
-emergency this system will track (among other things) if any entity:
-
-* Has power
-* Has sufficient supplies
-* Is informed about the emergency
-
-This system will make use of digital services and modern methodologies to automate and simplify parts of the check-in process 
-to help the municipality prioritize its call/check-in list and response plan. Additionally, the system will validate contact 
-information regularly during non-emergency times to ensure the municipality has the most up-to-date information for each entity.
-
-### Non Goals
-What will this project not accomplish during its initial creation?
-
-- No front-end website or app
-- No outside data interactions
-- Non-city employee full login (dashboard, etc)
-- Statistical or analytical endpoints
-
-### Minimum Viable Product
-To use this product as quickly as possible we will be implementing the following features:
-- User creation
-- Contact creation
-- Entity creation
-- Contact->Entity linking
-- Contact single-use login check-in ability
-
-### Roadmap
-Milestones and project timelines can be viewed on the [Projects page](https://github.com/CodeForBaltimore/Bmore-Responsive/projects)
-
-## Technology and Code
-
-This project will make exclusive use of open-source software, packages, and contributions. The application is built with the following
-technologies:
-
-- Javascript (ES6)
-- [Node.js](https://nodejs.org/en/)
-- [Express.js](https://expressjs.com/)
-- [Sequelize](https://sequelize.org/v3/)
-- [Docker](https://www.docker.com/)
-- [Terraform](https://www.terraform.io/)
-
-Please see our [Tech Spec](/docs/Tech_Spec.md) for a full breakdown of the project and workflows.
-
-Please see our [Best Practices](/docs/Best_Practices.md) for code standards, git standards, and other guidance for writing clean and well 
-documented code.
-
-### Pull Request Process
-1. Ensure you thoroughly fill out the pull request form presented when submitting the request. 
-   This includes listing what work was done, what issues are resolved by that work, what tests
-   have been added, how to perform other tests or run the code, and other potentially relevant
-   notes. 
-2. Update the README.md with details of changes to the application, this includes new environment 
-   variables, exposed ports, useful file locations and/or container parameters.
-3. If you are on the project team you may merge the Pull Request in once you have the sign-off of one other developer, or if you 
-   do not have permission to do that, you may request the second reviewer to merge it for you.
-
-## Contact
-The best ways to get in touch with us is via Slack. An active Slack link can be found on our website:
-
-***[codeforbaltimore.org](https://codeforbaltimore.org/)***
-
-You can also reach out to the tech lead [Jason Anton](https://github.com/revjtanton) via email at [[email protected]](mailto:[email protected]).
-
-## Sources and Links
-We are also building a front-end application called [Healthcare Rollcall](https://github.com/CodeForBaltimore/Healthcare-Rollcall) to interact 
-with this backend API. To view that project, or to contribute to it, please visit the repo here: https://github.com/CodeForBaltimore/Healthcare-Rollcall
+Bmore-Responsive is an Open Source project maintained by [CodeForBaltimore](https://codeforbaltimore.org).  We welcome contributions to anyone that accepts the [project's license](./LICENSE) and abides by our [Code of Conduct](./docs/Code_of_Conduct.md).  For more details, please refer to [How to Contribute](./docs/HowToContribute.md) in our project Wiki.

README.md

@@ -1,7 +1,26 @@
 [![Build Status](https://travis-ci.org/CodeForBaltimore/Bmore-Responsive.svg?branch=master)](https://travis-ci.org/CodeForBaltimore/Bmore-Responsive) [![codecov](https://codecov.io/gh/CodeForBaltimore/Bmore-Responsive/branch/master/graph/badge.svg)](https://codecov.io/gh/CodeForBaltimore/Bmore-Responsive)
 
 # Bmore Responsive
-An API to drive disaster and emergency response systems.
+A simple, flexible API to support emergency response coordination.  Sample use cases include:
+
+- keeping track of local nursing home status and needs during a global pandemic
+- identifying hospitals lacking power during a natural disaster
+- assuring safety of hikers in a national park during a snow storm
+
+Bmore-Responsive provides the following primary features via a secure REST API:
+
+- Maintain set of Entities (could be hospitals, nursing homes, campers, etc)
+- Maintain set of Contacts for Entities (people who can provide status/need info for entities)
+- Capture of status/need information about Entities
+- User account and role management to enable secure authentication and authorization
+- Export of any data via CSV
+
+<<TODO: Conclude with reference to QuickStart and/or Wiki>>
+
+
+
+
+## --- Old README content below, Refactored version above ----
 
 <!-- TOC -->
 
@@ -25,22 +44,7 @@ An API to drive disaster and emergency response systems.
 
 <!-- /TOC -->
 
-## Documentation
-Detailed documents describing this project and its use are available in this repository. The documentation currently available is as follows:
--   [Best Practices](/docs/Best_Practices.md)
--   [Code of Conduct](/docs/Code_of_Conduct.md)
--   [Sequelize](/sequelize/README.md)
--   [Tech Spec](/docs/Tech_Spec.md)
--   [Terraform](/terraform/README.md)
-
-### API Spec
-Our API spec is on Swagger. You can view it here https://app.swaggerhub.com/apis/codeforbaltimore/bmoreResponsive or you can find the `swagger.json` file in our `docs` folder and use it via http://localhost:3000/api-docs/ when the app is running locally.  
-
-### Database Documentation
-Our database documentation can be found in the `/sequelize` directory or you can [click here](/sequelize/README.md)
 
-### Infrastructure and Deployment
-We have included a `terraform` option to deploy to AWS. For more information on how to use this feature, please see the [terraform](/terraform/README.md) directory.
 
 # Setup
 This setup section will focus on setting up the local dev environment. For more detailed instructions for how to deploy this to a production environment please see the section above this one :point_up:
@@ -59,7 +63,7 @@ This application is designed to work as an API driven by Express. To setup your
 ```
 npm install
 ```
-Once all dependencies are installed you will need to setup some environment variables to interact with your database and application. 
+Once all dependencies are installed you will need to setup some environment variables to interact with your database and application.
 
 ## Environment variables
 You will need to set some local environment variables to run this application. This is true even if you're using Docker.
@@ -77,11 +81,11 @@ The `DATABASE_URL` is not a very clear var name, and the string is broken down a
 An example of the `DATABASE_URL` would be `DATABASE_URL=postgres://postgres:postgres@localhost:5432/postgres`
 
 The various variables are defined as follows:
-- `NODE_ENV` = The label for your environment. 
+- `NODE_ENV` = The label for your environment.
 - `PORT` = The local port you wish to run on. Defaults to `3000`.
 - `DATABASE_URL` = The URL string for your db connection. For example: `postgres://user:[email protected]:5432/dbname`
 - `DATABASE_SCHEMA` = Your local database schema. Postgres default is `public`.
-- `JWT_KEY` = A secret value to generate JWT's locally. 
+- `JWT_KEY` = A secret value to generate JWT's locally.
 - `SMTP_HOST` = _optional_ hostname for the SMTP server used to send notification emails
 - `SMTP_PORT` = _optional_ port number for the SMTP server used to send notification emails
 - `SMTP_USER` = _optional_ username for the SMTP server used to send notification emails
@@ -92,7 +96,7 @@ The various variables are defined as follows:
 
 _We do not recommend using the default options for PostgreSQL. The above values are provided as examples. It is more secure to create your own credentials._
 
-**Warning**: If you are running Docker Toolbox instead of Docker Desktop (likely meaning you are running Windows 10 Home, not Professional) you will need to change your `.env` to reflect Docker running on a VM: 
+**Warning**: If you are running Docker Toolbox instead of Docker Desktop (likely meaning you are running Windows 10 Home, not Professional) you will need to change your `.env` to reflect Docker running on a VM:
 - `DATABASE_HOST`: The IP address Docker is running on. You can find this by running `docker-machine ip` but it's usually `192.168.99.100` instead of `localhost`
 - `DATABASE_URL`: This will need to be adjusted as well, for example `DATABASE_URL=postgres://postgres:postgres@localhost:5432/postgres` would become `DATABASE_URL=postgres://postgres:[email protected]:5432/postgres`
 
@@ -123,7 +127,7 @@ If you're running a database in another way then we trust you can sort it out on
 ### Sequelize
 To properly start the application the database needs to be built by Sequlize ahead of time. To do that run the following commands
 1. You must create your database tables without running the application by running `npm run db-create` first.
-2. _optional_ You can now seed your database if you wish by running `npm run db-seed`. 
+2. _optional_ You can now seed your database if you wish by running `npm run db-seed`.
 
 Example `/migrations` and `/seeders` scripts have been supplied. You can rollback your all seeded data at any time by running `npm run db-unseed` and delete all created tables with `npm run db-delete`.
 
@@ -138,17 +142,17 @@ Note that `DATABASE_URL` host location will be different depending on what OS yo
 Alternatively you can manually set the environment variables and not use a `.env` file by setting the following vars:
 ```
 -e NODE_ENV=development
--e PORT=3000 
+-e PORT=3000
 -e JWT_KEY=<your JWT phrase>
 -e DATABASE_URL=<your connection string>
 -e DATABASE_DATABASE_SCHEMA=<your database schema>
 ```
 
 ### docker-compose
-To use the `docker-compose.yml` file included you will first need to set [environment variables](#environment-variables). You **MUST** set your `DATABASE_HOST` to `db` to use the `docker-compose` solution. It is not recommended to use `docker-compose` for any reason other than to test a solution for a separate front-end component. 
+To use the `docker-compose.yml` file included you will first need to set [environment variables](#environment-variables). You **MUST** set your `DATABASE_HOST` to `db` to use the `docker-compose` solution. It is not recommended to use `docker-compose` for any reason other than to test a solution for a separate front-end component.
 
 # Using this product
-You may use this product to create and manage users for your front-end. 
+You may use this product to create and manage users for your front-end.
 
 To run the application--after the above steps are completed--run `npm start`.
 

docs/Best_Practices.md

@@ -1,39 +1,8 @@
 # Best Practices
-Code for Baltimore projects should be built with the intention of deploying on [Heroku](https://heroku.com) or [AWS](https://aws.amazon.com/). For details on Heroku Best Practices see their [developer documentation](https://devcenter.heroku.com/articles/node-best-practices).
+Here's an incomplete list of things that are inportant to consider when developing code to be controibuted to Bmore Responsive:
 
-<!-- TOC -->
 
-- [Best Practices](#best-practices)
-    - [Project Management](#project-management)
-        - [Projects](#projects)
-        - [Issues and Milestones](#issues-and-milestones)
-        - [Tagging Issues](#tagging-issues)
-    - [Code Quality Standards](#code-quality-standards)
-        - [Style Guides](#style-guides)
-    - [Static Code Analysis](#static-code-analysis)
-    - [Git and Branching](#git-and-branching)
-        - [Branch Names](#branch-names)
-        - [Merging and Pull Requests](#merging-and-pull-requests)
-
-<!-- /TOC -->
-
-## Project Management
-
-We are using Github Issues to track outstanding issues and work for projects. 
-
-### Projects
-
-Github Projects help organize our repositories by creating a Kanban board to track issues. These boards can be automatically generated by Github when creating the Project and should include a Todo, In Progress, Under Review, Reviewer Approved, and Done column. As issues are added to a Project they should be added to the board. A repo can have one or many Projects or boards at any given time.
-
-### Issues and Milestones
-
-When breaking down work it is important to add tasks to the Github project. For convenience various types of issues have templates built into this repo for easy issue entry. Before tasks are entered the project managers should agree on milestones based on the Project objectives. Issues should be tracked against Milestones so progress can be measured and planned for.
-
-### Tagging Issues
-
-When entering issues tagging can be used to further organize work or make work more visible to team members.
-
-## Code Quality Standards
+### Code Quality Standards
 
 Regardless of Language:
 
@@ -50,19 +19,19 @@ Consistent style guidelines for each language should be used. Where possible, op
 Example: Google has openly published style guides for many languages in wide use on their open source projects, and these can be adopted for use in this project: [Google Language Specific Styleguides](https://google.github.io/styleguide/)
 
 
-## Static Code Analysis
+### Static Code Analysis
 
 Static code analysis tools should be used when possible, to monitor and improve code quality. This may be integrated in the local development environment, automated repository commit checks, automated CI/CD pipelines, or other steps in the code development process.
 
-## Git and Branching
+### Git and Branching
 
 All code work should be done in an isolated or feature branch off of the `master` branch.  Before starting work on new code, developers should create their feature branch using a standard naming convention determined by the project.  
 
 ### Branch Names
-Branch names should follow this patter: `<your github username>/issue-<github issue number>`. This will ensure there are no branch name conflicts, and anyone looking for your branch will know what it is called based on the issue addressed. For example if your username was `letsGoOs`, and you were working on issue 8, then your branch name would be `letsGoOs/issue-8`. If you wanted to make a new branch to continue your work on your issue then add a suffix with an incremented number. To continue the previous example if you wanted to make a second branch for your issue 8 work your second branch would be called `letsGoOs/issue-8-2`.
+Branch names should follow this pattern: `<your github username>/issue-<github issue number>`. This will ensure there are no branch name conflicts, and anyone looking for your branch will know what it is called based on the issue addressed. For example if your username was `letsGoOs`, and you were working on issue 8, then your branch name would be `letsGoOs/issue-8`. If you wanted to make a new branch to continue your work on your issue then add a suffix with an incremented number. To continue the previous example if you wanted to make a second branch for your issue 8 work your second branch would be called `letsGoOs/issue-8-2`.
 
 ### Merging and Pull Requests
 
 When work is complete, and after static code analysis has been performed, the developer should submit a pull request in Github.  A pull request template has been provided, and developers should take care to fill out the form as completely as possible when submitting new pull requests omitting any sections that are deemed unnecessary for that particular submission.  Pull requests should require at least 1 review from another verified team member before they are approved and merged into the `master` branch.  
 
-While not strictly required, it is recommended that pull requests are submitted early on in the development process with the intention of maintaining high visibility over the work while it is in progress. 
+While not strictly required, it is recommended that pull requests are submitted early on in the development process with the intention of maintaining high visibility over the work while it is in progress.