Merge pull request #2435 from ustaxcourt/staging

Merge staging into prod

Author: jimlerza

cypress-smoketests/support/pages/trial-sessions.js

@@ -55,8 +55,8 @@ exports.createTrialSession = (testData, overrides = {}) => {
 
   cy.get('#chambers-phone-number').type(faker.phone.number());
   cy.get('#trial-clerk').select(testData.trialClerk || 'Test trialclerk1');
-  cy.get('#court-reporter').type(faker.name.findName());
-  cy.get('#irs-calendar-administrator').type(faker.name.findName());
+  cy.get('#court-reporter').type(faker.name.fullName());
+  cy.get('#irs-calendar-administrator').type(faker.name.fullName());
   cy.get('#notes').type(faker.company.catchPhrase());
 
   cy.get('#submit-trial-session').click();

docs/README.md

@@ -26,6 +26,13 @@ If you're ready for the challenge, navigate to the [Getting Started Guide](/gett
 
 Otherwise, if you're just interested in a particular topic, you can find it in the sidebar.
 
+## Onboarding Resources
+
+The onboarding checklist and quick reference guide will be handy as you navigate your first couple months. Please reach out to your onboarding buddy with questions. If you don't have a buddy and want one, please ask the team about it!
+
+1. [Onboarding Checklist](https://docs.google.com/document/d/12twlx5nLG6B4R6ds96wh_gZ6wR5Y_PGjsmSeP98V6o0): Make a copy as this will be your personal checklist of important tasks as you onboard
+2. [Onboarding Quick Reference Guide](https://docs.google.com/document/d/1ObraR8X5YUzR1GIwsm903EhS7-AQbpy90--5aAWysKU): A hodge-podge of helpful links, information, who's who, what's what
+
 ## Looking for Old Docs?
 
 Most of the older documentation was moved directly into this docsify directory.  The goal is to eventually incorporate them into the top level sections of this documentation, or move them to a common sub directory if they don't fit well into the incremental introduction approach the documentation is attempting to follow. They can be found on one of the following links:

docs/additional-resources/blue-green-migration.md

@@ -4,24 +4,30 @@
 
 Every deployment, whether it's to production or a development environment, is a blue-green deployment. We build a copy for the resources that are required to run a second version of the application. When the copy is ready and tested, we switch the client over to run off of the newly deployed color and have the old color available for rolling back.
 
-Additionally, for deployments that require change in the data schema or broad stroke changes to the database in order for the application to function, we build an empty copy of the data stores (DynamoDB and Elasticsearch). Then we perform a migration of information from the old data store into the newly created one. This migration passes all of the data through a lambda to update and verify the data before saving it into a new data store.
+Additionally, for deployments that require change in the data schema or elasticsearch mappings in order for the application to function, we build an empty copy of the data stores (DynamoDB and Elasticsearch). Then we perform a migration of information from currently running DynamoDB database table (*source table*) into the newly created, empty one (*destination table*). This migration passes all of the data through a lambda to update and verify the data before saving it into the destination table.
 
 ## Automated Migration Steps
 
 **All of the automated migration steps are now handled by CircleCI, as defined in `config.yml`.**
 
 Some key steps, excluding automated tests, include:
 
+### Manual Steps required before attempting an automated Migration
+
+If the destination table exists in either `us-east-1` or `us-west=1`, you will have to delete it before kicking off a CircleCI deployment.
+
 ### Deploy, Migrate, and Reindex
+
 - Deploy updated infrastructure.
 - `migrate` is automatically determined if there are expected migration scripts that do not exist in the DynamoDB table.
-    - Disable destination table stream.
-    - Migration runs.
-    - SQS queue empties.
-    - Enable destination table stream.
+  - Disable destination table stream.
+  - Migration runs.
+  - SQS queue empties.
+  - Enable destination table stream.
 - ElasticSearch reindexes, and a cron runs to determine if the reindex completes. This will approve the next step in the workflow to run.
 
 ### Post-successful Deploy
+
 - Switch the current color and deployed color.
 - If deploying the `prod` environment, backup the source's DynamoDB table.
 - Delete the source's API gateway mappings, both non-public and public.
@@ -30,12 +36,80 @@ Some key steps, excluding automated tests, include:
 - Delete the source's DynamoDB table in `east` and `west` regions.
 - Toggle the deploy table's values for `migrate` and `source-table-version`.
 
-
 ## Manual Migration Steps
 
 The application kicks off a migration automatically if it detects migrations that need to be run in the codebase that haven't yet been run upon that environment. In order to force a migration, perform the following manual steps. You might do this if you were doing a package update that might impact the migration and wanted to test it fully.
 
-1. Remove a migration script item from the environment's `efcms-<ENV>-deploy` DynamoDB table that is expected to migrate, from the `migrationsToRun.js` file. For example, if `migrationsToRun.js` includes a script called `0001-test-script.js`, delete that item from the DynamoDB table.
-2. Kick off a CircleCI workflow, which will follow the steps above for Automated Migration Steps.
+There are two good ways to trigger a manual migration. You can either [remove the record from the deploy table](#remove-record-of-previous-migration) of one of the previously run migrations, or you can [explicitly configure the deploy table to run a migration](#explicitly-configure-deploy-table) on next deploy.
+
+The first step of either is to [delete the destination table](#delete-the-destination-tables)
+
+### Delete the Destination Tables
+
+We need to delete the destination tables (if they exist) in order to perform a blue green migration. It is preferred to delete the `west` table first mainly because we are using a  DynamoDB Global table and replication.
+
+The `east` table is master table, and if you delete these tables and recreate them. You will be unable to delete the `east` table until you delete the `west` table. AWS will throw an error if you attempt to delete the `east` table before the `west` table if both exist and they have been deleted within the last 24 hours.
+
+#### Via the command line
+
+1. Identify the **destination table**. For example, if we're performing a deployment to `dev`:
+
+    ```bash
+    $ ./scripts/dynamo/get-source-table.sh dev
+    efcms-dev-beta
+    $ ./scripts/dynamo/get-destination-table.sh dev
+    efcms-dev-beta
+    ```
+
+    Both should be the same value, and that is what the application is currently using as it its main data store. If they are both `alpha`, then the destination table is `beta`. If they are both `beta`, the destination table is `alpha`.
+
+    If they are different, inspect the Lamdba's environment config to determine what table the application is currently using. If that is `beta`, then the destination table is `alpha`, and vice versa.
+
+2. Check to see if the **destination table** exists. You can do this via the AWS Console or AWS CLI:
+
+    ```bash
+    $ aws dynamodb describe-table --table-name efcms-dev-alpha
+    ```
+
+    If you get an error, `An error occurred (ResourceNotFoundException) when calling the DescribeTable operation: Requested resource not found: Table: efcms-dev-alpha not found`, then you are ready to proceed with the deployment.
+
+    If you do not, then it exists, and you must delete the table.
+
+3. If it exists, delete the **destination table** in both `east` and `west`. You can do this via the AWS Console or AWS CLI:
+
+    ```bash
+    $ aws dynamodb delete-table --table-name efcms-dev-alpha --region us-west-1
+    $ aws dynamodb delete-table --table-name efcms-dev-alpha --region us-east-1
+    ```
+
+    NOTE: after deleting the `west` table, you may have to wait a few minutes before you can delete the `east` table.
+
+
+#### Via the console
+
+1. Identify the source table and destination table. Both should be the same value, and that is what the application is currently using as it its main data store. If they are both `alpha`, then the destination table is `beta`. If they are both `beta`, the destination table is `alpha`. If they are different, inspect at the current color Lamdba's environment config to determine the dynamo table that the application is currently using as its data store.
+2. Change the value for the `current` key of the `pk`:`destination-table-version` to the destination table you identified in step 3 (`alpha` or `beta`).
+3. Switch to the `west-1` region.
+4. Delete the destination table in `west`
+5. Go back to east region
+6. Delete the destination table in `east`; note this may take a few minutes as the west table is deleting.
+
+### Remove Record of Previous Migration
+
+1. Delete the Destination table [see instructions](#delete-the-destination-tables)
+2. Remove a migration script item from the environment's `efcms-<ENV>-deploy` DynamoDB table that is expected to migrate, from the `migrationsToRun.js` file. For example, if `migrationsToRun.js` includes a script called `0001-test-script.js`, delete that item from the DynamoDB table.
+3. Kick off a CircleCI workflow, which will follow the steps above for Automated Migration Steps.
+
+### Explicitly Configure Deploy Table
+
+1. Go into the environment's deploy table `efcms-<ENV>-deploy`
+2. Change the `migrate` flag to `true`
+3. Identify the source table and destination table. Both should be the same value, and that is what the application is currently using as it its main data store. If they are both `alpha`, then the destination table is `beta`. If they are both `beta`, the destination table is `alpha`. If they are different, inspect at the current color Lamdba's environment config to determine the dynamo table that the application is currently using as its data store.
+4. Change the value for the `current` key of the `pk`:`destination-table-version` to the destination table you identified in step 3 (`alpha` or `beta`).
+5. Switch to the `west-1` region.
+6. Delete the destination table in `west`
+7. Go back to east region
+8. Delete the destination table in `east`; note this may take a few minutes as the west table is deleting.
+9. Kick off a CircleCI workflow, which will follow the steps above for Automated Migration Steps.
 
 See [the troubleshooting guide](TROUBLESHOOTING.md) for solutions to problems that may arise during the migration process.

docs/team-process.md

@@ -2,15 +2,6 @@
 
 Now that you've logged in and played around with our Dawson system a bit on a deployed environment, let's talk about our team process and what is expected from our fellow teammates.  This part of the documentation should help members get on the same page when it comes to the soft-skills required to work as a well-oiled agile machine.
 
-## Onboarding
-
-Here are some few resources for documentation associated with onboarding:
-
-1. [Onboarding checklist](https://docs.google.com/document/d/1zhvp8vcWnVSvUbTKZ-0sHrf5lA6OTlpXqvjeLgKJtVk)
-2. [Onboarding Reference Guide](https://docs.google.com/document/d/1jOd0wAsqTDBKsFeEvUj9ezvdTimTsqTwkYd6Imibl3c)
-
-If you do not have permissions to view these documents, please reach out to the document owner.
-
 ## Working Agreement
 
 We have talked about writing some form of working agreement so team members have a common understanding of what is expected from them during their daily work.  Great teams strive for open communication, safe spaces to speak their mind, and continuous improvement in process.  Embracing some of the following ideologies will help grow and sustain a healthy team.
@@ -158,9 +149,14 @@ If dependencies have no patch, replace it with an alternative, or wait for the l
 
 Below is a list of dependencies that are locked down due to known issues with security, integration problems within DAWSON, etc. Try to update these items but please be aware of the issue that's documented and ensure it's been resolved.
 
-- `@fortawesome` packages locked down to versions pre-6.x.x to maintain consistency of icon styling until there is usability feedback and research that determines we should change them. This includes packages:
-  - `@fortawesome/free-solid-svg-icons`
-  - `@fortawesome/free-regular-svg-icons`
-  - `@fortawesome/fontawesome-svg-core`
-
-- It'd be good to keep an eye on `s3rver` for when it exceeds 3.7.1. We have a patch in place for called `s3rver+3.7.1.patch` in order to address the high severity issue exposed by `s3rver`'s dependency on `busboy` 0.3.1, which relies on `dicer` that actually has the [security issue](https://github.com/advisories/GHSA-wm7h-9275-46v2). Unfortunately, `busboy` >0.3.1, aka ^1.0.0, is incompatible with s3rver which is why there's a patch in place to make it compatible.
+1. `@fortawesome` packages locked down to versions pre-6.x.x to maintain consistency of icon styling until there is usability feedback and research that determines we should change them. This includes packages:
+    - `@fortawesome/free-solid-svg-icons`
+    - `@fortawesome/free-regular-svg-icons`
+    - `@fortawesome/fontawesome-svg-core`
+
+2. Check if there are updates to `s3rver` above version [3.7.1](https://www.npmjs.com/package/s3rver). 
+    - Why is there a patch called `s3rver+3.7.1.patch`?
+      - To address the high severity issue exposed by `s3rver`'s dependency on `busboy` 0.3.1, which relies on `dicer` that actually has the [security issue](https://github.com/advisories/GHSA-wm7h-9275-46v2). Unfortunately, `busboy` >0.3.1, aka ^1.0.0, is incompatible with s3rver which is why there's a patch in place to make it compatible. 
+    - How does the patch run?
+      - This runs as part of the `npm postinstall` step. 
+    - Common troubleshooting: If you see the high severity audit issue warning for  `dicer`, run a full `npm install` rather than a single package update, as this will run the `postinstall` which is required to run the patch that addresses the security issue.

docs/testing.md

@@ -311,9 +311,9 @@ This will run the linter, Shellcheck, audit, build, test, Cypress, Cerebral test
 
 ## PDF Testing
 
-Since our system generates a lot of PDFs, we have a set of tests that verify the pdfs didn't change using a checksum of the first exported image of the pdfs.  Since all of these PDFs share a single .scss file, there is risk involved when trying to update a single PDF to accidentally change the styles of other PDFs.  Therefore, we have a set of tests that verify that the PDFs are not changing.
+Since our system generates a lot of PDFs, we have a set of tests that verify the PDFs didn't change using a checksum of the first exported image of the PDFs.  Since all of these PDFs share a single .scss file, there is risk involved when trying to update a single PDF to accidentally change the styles of other PDFs.  Therefore, we have a set of tests that verify that the PDFs are not changing.
 
-If you are adding/creating a new PDF you must add the PDF name to the pdfs array in image-compare-pdfs.js.
+If you are adding/creating a new PDF you must add the PDF name to the `pdfs` array in image-compare-pdfs.js.
 
 All of the expected output images are found in the `./shared/test-pdf-expected-images` directory.  In order to update these, you will need to run the following command:
 

iam/terraform/environment-specific/main/update-petitioner-cases-lambda-role.tf

@@ -57,15 +57,6 @@ resource "aws_iam_role_policy" "iam_update_petitioner_cases_lambda_policy" {
             ],
             "Effect": "Allow"
         },
-        {
-            "Action": [
-                "ses:SendBulkTemplatedEmail"
-            ],
-            "Resource": [
-                "arn:aws:ses:us-east-1:${data.aws_caller_identity.current.account_id}:identity/noreply@${var.dns_domain}"
-            ],
-            "Effect": "Allow"
-        },
         {
             "Action": [
                 "s3:DeleteObject",
@@ -94,6 +85,14 @@ resource "aws_iam_role_policy" "iam_update_petitioner_cases_lambda_policy" {
             ],
             "Resource": "arn:aws:sqs:us-east-1:${data.aws_caller_identity.current.account_id}:update_petitioner_cases_queue_${var.environment}_*",
             "Effect": "Allow"
+        },
+        {
+            "Action": [
+                "sqs:SendMessage",
+                "sqs:DeleteMessage"
+            ],
+            "Resource": "arn:aws:sqs:us-east-1:${data.aws_caller_identity.current.account_id}:send_emails_queue_${var.environment}_*",
+            "Effect": "Allow"
         }
     ]
 }

lint-pa11y.js

@@ -0,0 +1,26 @@
+const { execSync } = require('child_process');
+
+/** Map of forbidden words and their match regex */
+const words = {
+  only: '\\s*only\\:',
+};
+
+let status = 0;
+for (let word of Object.keys(words)) {
+  const matchRegex = words[word];
+  const gitCommand = `git diff --staged -G"${matchRegex}" --name-only`;
+  const badFiles = execSync(gitCommand).toString();
+  const filesAsArray = badFiles.split('\n');
+  const jsFileRegex = /\.js$/;
+  const onlyJsFiles = filesAsArray.filter(file =>
+    jsFileRegex.test(file.trim()),
+  );
+  if (onlyJsFiles.length) {
+    status = 1;
+    console.log(
+      `The following files contain a focused pa11y test with '${word}' in them:`,
+    );
+    console.log(onlyJsFiles.join('\n'));
+  }
+}
+process.exit(status);