Merge pull request #313 from nci-ats/dev

Sprint 6 v0.0.13

README.md

@@ -51,7 +51,7 @@ This repository is being development under a task order of the Agile Blanket Pur
   - AWS_REGION
   - AWS_BUCKET_NAME
   - SUDS_API_URL
-    - To point at mocks, update this to be `http://localhost:${PORT}/mocks`
+    - To use the moxai dependency and point at the mock API, update this to be `http://localhost:${PORT}/mocks`.
 
 - Dotenv:
   - [Dotenv](https://www.npmjs.com/package/dotenv) is used which can load environment variables from a .env file into process.env
@@ -74,6 +74,10 @@ Refer to application package and dependency trackers for additional dependency i
   - [VersionEye](https://www.versioneye.com/user/projects/58a669e7b4d2a20055fcb84c)
   - [Bithound](https://www.bithound.io/github/nci-ats/fs-middlelayer-api/feat%2Fswagger-ui/dependencies/npm)
 
+The Moxai package is a dependency for testing and was built specifically for this project. Moxai was published as an [independent package](https://www.npmjs.com/package/moxai) that can be used with any Express application. This application uses the moxai package as a placeholder mock API. The /mocks/basic.json file maintains the API endpoint schema. 
+
+The controllers/index.js file has random control number generation logic that should be removed when the mock API is replaced with the Basic API.
+
 ## Point of Contact and Notifications
 
 You can report issues and submit questions by opening a new [Issue](https://help.github.com/articles/creating-an-issue/) in GitHub. You can [Watch](https://help.github.com/articles/watching-repositories/) this repo to receive notifications from GitHub when a new issue is posted, when an existing issue’s status is updated, and when a pull request is created.

docs/ci-cd.md

@@ -1,8 +1,8 @@
 # Travis CI
 
-Travis is configured using the `.travis.yml` file created in the core repository.
+[Travis CI](https://docs.travis-ci.com/) (continuous integration) is configured using the `.travis.yml` file created in the core repository.
 
-Travis CI is configured to build on each commit or on each pull request.
+Travis is triggered to build with every commit and pull request creation or merge.
 
 The build process includes the following steps:
 
@@ -12,4 +12,4 @@ The build process includes the following steps:
     2. `npm run lint`
     3. `istanbul cover ./node_modules/mocha/bin/_mocha --report lcovonly -- -R spec --recursive`
     4. `codecov`
-3. If the build is successful, Travis automatically deploys the build to Heroku. An `api_key` in `.travis.yml` directs the deployment to `fs-epermit-dev`. 
+3. A successful build on a PR merge triggers a branch-dependent deployment to cloud.gov or Heroku. An `api_key` in `.travis.yml` directs the deployment to `fs-epermit-dev`. 

docs/code-quality.md

@@ -0,0 +1,31 @@
+# Code Quality and Coverage
+
+We are using the following packages for maintaining code quality and coverage.
+
+## Code Quality
+
+### ESLint
+
+[ESLint](https://www.npmjs.com/package/eslint) is a pluggable linting utility for JavaScript. The linting configuration and rules are provided in the `.eslintrc.json` file. Use `npm run lint` to run ESLint.
+
+### MarkdownLint
+
+[MarkdownLint](https://www.npmjs.com/package/markdownlint) is a static analysis tool with a library of rules to enforce standards and consistency for Markdown files.
+The linting configuration and rules are provided in the `.markdownlint.json` file.
+Use `npm run lint:md` to run MarkdownLint.
+
+###  JSDoc
+
+[JSDoc](https://www.npmjs.com/package/jsdoc) is an API documentation generator for JavaScript.
+JSDoc documentation is available in the `/docs/code` folder and accessed via `<application-URL>/docs/code`. Use `npm run doc` to run JSDoc.
+
+## Code Coverage
+
+###  Codecov 
+
+We use [Istanbul](https://www.npmjs.com/package/istanbul) to run the Mocha test cases. [Codecov](https://www.npmjs.com/package/codecov) makes the Instanbul test coverage report available to Travis CI.
+Using `npm run coverage` runs the `istanbul cover ./node_modules/mocha/bin/_mocha -- --recursive` command. This command runs the tests and creates the report in `/coverage`. The coverage indicates the percentage of code covered by unit testing.
+
+### Code Climate
+
+[Code Climate](https://www.npmjs.com/package/codeclimate) is another tool for generating [unit test coverage reports](https://codeclimate.com/github/nci-ats/fs-middlelayer-api/code). Code Climate is configured in the `.codecov.yml` file.

docs/permit-creation.md

@@ -3,11 +3,11 @@
 These steps define the process for creating a new permit type using Example Permit.
 
 1. Create Swagger Documentation.
-    1. Go to `src/api.json` and add the new `GET`, `PUT`, and `POST` route for the new Example Permit as shown below:
+    1. Go to the `src/api.json` Swagger document file and add the new `GET`, `PUT`, and `POST` route for the new Example Permit as shown below:
 
         `/permits/applications/special-uses/commercial/example-permit/`
 
-    2. Add the relevant application form fields for these routes. </br>
+    2. Create the GET endpoint for the new permit with the relevant application form fields in the Swagger document. </br>
         Example `GET` in `api.json`:
 
             /permits/applications/special-uses/commercial/example-permit{controlNumber}/: {
@@ -26,18 +26,19 @@ These steps define the process for creating a new permit type using Example Perm
 
         Intake options include:
         - `middleLayer/<fieldName>`
-          - From the application table in middleLayer database, column name <fieldName>
+          - From the application table in middleLayer database, column name `<fieldName>`
         - `addresses/<fieldName>`
-          - From Basic API response, addresses array
+          - From Basic API response JSON; using the first element of the `addresses` array, `<fieldName>` is the key of the key value pair
         - `holders/<fieldName>`
-          - From Basic API response, holders array
+          - From Basic API response JSON; using the first element of the `holders` array, `<fieldName>` is the key of the key value pair
         - `phones/<fieldName>`
-          - From Basic API response, phones array
+          - From Basic API response JSON; using the first element of the `phones` array, `<fieldName>` is the key of the key value pair
         - `<fieldName>`
           - From Basic API response, not in any array
 
 
-    3. Example `POST` in `api.json`:
+    3. Create the POST endpoint for the new permit with the relevant application form fields. </br>
+        Example `POST` in `api.json`:
 
             "/permits/applications/special-uses/commercial/example-permit/": {
                 "post": {
@@ -73,7 +74,8 @@ These steps define the process for creating a new permit type using Example Perm
                     "required": ["region","forest","district"...]
                 }
 
-      4. Example `POST` in `validation.json`:
+    4. The `validation.json` is a schema file for validating submitted data through `POST` routes.</br>
+        Example `POST` in `validation.json`:
 
                 "district": {
                     "default":"",
@@ -113,7 +115,9 @@ These steps define the process for creating a new permit type using Example Perm
                 },
 
 
-          - `fromIntake` indicates whether the field will be directly populated with user input. If set to `false`, `madeOf` must be provided, giving the fields, or strings used to populate this field.
+          - `fromIntake` indicates whether the field will be directly populated with user input. If set to `false`, the API will populate this field using the strings and fields provided under `madeOf`.
+
+          - `store` describes where this field should be stored, either in the middlelayer DB or in the basic API. It can list multiple places to store this field
 
           Files:
           - `maxSize` is measured in megabytes
@@ -128,7 +132,7 @@ These steps define the process for creating a new permit type using Example Perm
           If the store contains one of the `basic` type options, `basicField` attribute must be included. This is the name of the field used to submit this data to the Basic API.
 
 2. Extend the schema, if necessary.
-    1. If there are any new form fields not supported by the current middle-layer  database, they can be added in the application table. To do this, go to `dba/migrations/ 02-create-applications.js` and update the sequelize migration script as needed. Also, update `src/models/applications.js` to include the new database fields.
+    1. If there are any new form fields not supported by the current middle-layer  database, they can be added in the application table. To do this, go to `dba/migrations/ 02-create-applications.js` and update the sequelize migration script as needed. Also, update `src/models/applications.js` to include the new database fields. This applies only if you are recreating the applications table. Please refer to the [Sequelize migrations documentation](http://docs.sequelizejs.com/en/latest/docs/migrations/) for information on altering an existing table.
     2. If there are routing changes, update `src/controllers/index.js`.
     3. If there are validation changes, update `src/controllers/validation.js`.
     4. If there are any changes on how the files are to be stored, update `src/controllers/store.js`.

docs/testing.md

@@ -11,12 +11,12 @@ These two files contain unit testing test cases:
 - `test/controllers-test.js`
 - `test/functions-test.js`
 
-## API Tests
+## API Tests (Integration Tests)
 
 API tests run the test case against the API routes.
 
 These three files contain the API testing test cases:
-- `test/authetnication.js`
+- `test/authentication.js`
 - `test/noncommercial.js`
 - `test/outfitters.js`