Merge branch 'main' of https://github.com/Enterprise-CMCS/managed-car…

…e-review into mcr-3836-modify-app-api-to-work-with-authorizer

dev_tool/package.json

@@ -20,9 +20,9 @@
         ]
     },
     "dependencies": {
-        "@aws-sdk/client-cloudfront": "^3.450.0",
-        "@aws-sdk/client-ec2": "^3.441.0",
-        "@aws-sdk/client-secrets-manager": "^3.441.0",
+        "@aws-sdk/client-cloudfront": "^3.485.0",
+        "@aws-sdk/client-ec2": "^3.485.0",
+        "@aws-sdk/client-secrets-manager": "^3.485.0",
         "node-ssh": "^13.1.0",
         "yargs": "^17.2.1"
     },

docs/technical-design/contract-rate-change-history.md

@@ -9,6 +9,28 @@ Change history is the feature of MC-Review where the application stores full cop
 
  This document details how the change history is calculated for contract and rate data and which database fields are used.
 
+## Diagram
+[Miro link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764574794469060&cot=14)\
+![contract-and-rate-history-diagram](../../.images/contract-and-rate-history-diagram.png)
+
+In this diagram when a contract or rate is unlocked, a new draft revision version is created from the previous submitted revision. When submitted the draft revision is turned into a submitted revision that is then a part of the revision history.
+
+### Reading history
+[Miro Link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764574799194467&cot=14)\
+![reading-contract-history](../../.images/read-contract-and-rate-history-diagram.png)
+
+#### Example 1
+In example 1, we are fetching the contract data on 1/20/2024 (pretend that proceeding actions have not occurred yet).
+On this date, the contract has been unlocked and Rate B was removed from the contract.
+When unlocking a contract or rate, a new draft revision is made. Any changes made to the contract or rate is reflected in these draft revisions.
+Until the contract or rate is submitted, the draft revision will remain in the data when we fetch.
+So when fetching on the unlocked contract on 1/20/2024 the data will return with a draft revision for the contract, then the revision history in reverse order.
+
+#### Example 2
+In example 2, we are fetching the contract on 1/21/2024 in a submitted state.
+In this example there are no draft revisions, so the data returned is just the revision history.
+You will notice that in at this date and time the contract, Contract Rev 4, that was in draft state on 1/20/2024 is no longer in draft state and now in the contract history column. When a contract or rate that is unlocked gets resubmitted its drafts are turned into a historical revision.
+
 ## Contraints
 - MC-Review must track version history once a contract or rate is submitted.
     - This includes all actions on contract or a rate (submit, unlock, resubmit) alongside the related form data present at that point in time in the database.
@@ -30,18 +52,22 @@ At the Postgres Table level, draft revisions and submitted revisions live in the
 The list of revisions returned from prisma is run through [Zod](https://zod.dev/) to return [domain mode types](../../services/app-api/src/domain-models/contractAndRates). This is initiated by the `*WithHistory` database functions. See [parseContractWithHistory](../../services/app-api/src/postgres/contractAndRates/parseContractWithHistory.ts) and [parseRateWithHistory](../../services/app-api/src/postgres/contractAndRates/parseRateWithHistory.ts).
 
 #### Contract History
+- **Below a temporary approach to finding the contract history. The correct way to build the actual contract and rate history will be done in the [Rate Change History epic](https://qmacbis.atlassian.net/browse/MCR-3607)**
 - `parseContractWithHistory` takes our prisma contract data and parses into our domain `ContractType`. In `ContractType` the `revisions` is an array of **contract** **revisions**; this is the contract history.
 - `revisions` differs from `draftRevision` in the `ContractType`. The `draftRevision` is a singular revision that is not submitted and this data has no historical significance until it is submitted. Most of the data in this revision can be updated.
 - Each **contract revision** in `revisions` is submitted and retains data at the time of the submission. These revision's data will never be updated to retain its historical integrity.
 - An important note about the `rateRevisions` field in each contract revision in `revision`.
-   - Like contracts, rates also have **rate revisions** which are used to construct a rate history through submissions, but the purpose of `rateRevisions` on a contract revision is not for rate history.
-   - The purpose of `rateRevisions` is to retain the data of a rate linked to this contract revision at the time of submission.
-   - For that we need the single rate revision that was submitted at the time this contract revision was submitted.
+   - Like contracts, rates also have **rate revisions** which are used to construct a rate history through submissions, **but the purpose of `rateRevisions` on a contract revision is not for rate history**.
+   - The purpose of `rateRevisions` is to retain the latest data of a rate linked to this contract revision before the proceeding contract revision.
+     - For that we need the single rate revision that was submitted before the proceeding contract revision was unlocked.
    - Here are some guidelines for each rate revision in `rateRevisions` of a contract revision.
+      - Rate can be unlocked and resubmitted independently of the contract. This means that for a rate that belongs to a contract, the number of rate revisions on that contract revision is not 1-to-1.
+         - If a contract is submitted with a rate, that rate can be unlocked and resubmitted many times so there would be many revisions.
+         - Each revision would belong to that contract revision up until proceeding contract revision, where it would be a new point in the contract history.
+         - This will retain the latest rate data up until the next point in the contract history and ensure that when fetching a contract, the correct rate data will be returned.
       - Each rate revision in `rateRevisions` is unique by rate id, meaning there will never be two rate revisions with the same rate id in `rateRevisions`
-      - Each rate revision is the latest submitted up till the contract revision submitted time.
-      - Like contract revision, rate revision is read only and cannot be updated to retain its historical integrity.
-
+      - Each rate revision is the latest submitted up till the proceeding contract revision unlocked time.
+      - If the rate revision has a `true` value for the field `isRemoval` then, it is not included in the contract. This field signifies that the rate has been removed from the contract.
 
 *Dev Note*: If the `draftRevision` field has a value and the `revisions` field is an empty array, we know the Contract or Rate we are looking at is an initial draft that has never been submitted.
 

docs/technical-design/howto-migrations.md

@@ -69,9 +69,12 @@ This type of migration is run as standalone lambda that developers must manually
     - Start with DEV. Follow similar steps Step #4 but now using the `main` lambda for your migration.
     - Run the migration DEV > VAL > PROD in order, verifying in the application (or via reporting output) after each run.
 
-## How to dump VAL data for local testing
+## How to dump deployed data for local testing
 
-1. use `./dev jumpbox clone val` to clone the val database to your local machine
+1. Connect to Aurora Postgres via AWS Jump Box. [Instructions](../../services/postgres/README.md#access-to-aurora-postgres-via-aws-jump-box)
 
-2. Load that db dump into your local running postgres instance
-    - `pg_restore -h localhost -p 5432 -U postgres -d postgres --clean val-[date].sqlfc`. You will be promoted to enter in local db password `shhhsecret`. You will see print out errors but the database has spun up successfully.
+2. Use `./dev jumpbox clone [environment]` to clone the environment database to your local machine. This command will log into the jumpbox, dump the db into a file in the format `dbdump-[environment]-[date].sqlfc`, and copy that file locally.
+
+2. Load that db dump into your local running postgres instance.
+   - Copy the dump file to the `mc-postgress` docker container by running the command `docker cp dbdump-[env]-[date].sqlfc mc-postgres:/` from where the file is located.
+   - Then run the command `docker exec -it mc-postgres pg_restore -h localhost -p 5432 -U postgres -d postgres --clean dbdump-[env]-[date].sqlfc`. You will be promoted to enter in local db password `shhhsecret`. You will see print out errors but the database has spun up successfully.

docs/technical-design/resovler-design.md

@@ -21,7 +21,7 @@ Many of these functions are accessible from the resolver via [dependency injecti
 Errors from these functions propagate up to the resolver where it will be handled and a response sent to the client. See docs about [error handling](error-handling.md) for details.
 
 ### Diagram
-[Miro link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764573512051070&cot=14)
+[Miro link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764573512051070&cot=14)\
 ![resolver-design-diagram](../../.images/resolver-design-diagram.png)
 
 ## General Guidance
@@ -34,7 +34,7 @@ Resolvers are passed Postgres handlers via [dependency injection](design-pattern
 
 The diagram below is the data flow diagram for `createHealthPlanPackage` resolver.
 
-[Miro link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764573517610448&cot=14)
+[Miro link](https://miro.com/app/board/o9J_lS5oLDk=/?moveToWidget=3458764573517610448&cot=14)\
 ![postgres-handler-diagram](../../.images/postgres-handler-diagram.png)
 
 Form the diagram above, you can see that `createHealthPlanPackage` resolver calls `insertDraftContract` handler function in the Postgres Module to create a new draft contract. 

scripts/destroy_stage.ts

@@ -10,6 +10,7 @@ import {
     ListObjectVersionsCommand,
     DeleteObjectsCommand,
     PutBucketVersioningCommand,
+    PutBucketVersioningCommandInput,
 } from '@aws-sdk/client-s3'
 
 const AWSConfig = {
@@ -234,7 +235,7 @@ async function turnOffVersioningOnBucket(
         `Turning off bucket versioning on bucket: ${bucket.PhysicalResourceId}`
     )
 
-    const versionParams = {
+    const versionParams: PutBucketVersioningCommandInput = {
         Bucket: bucket.PhysicalResourceId ?? '',
         VersioningConfiguration: { Status: 'Suspended' },
     }

scripts/package.json

@@ -18,9 +18,9 @@
         ]
     },
     "dependencies": {
-        "@aws-sdk/client-cloudformation": "^3.202.0",
-        "@aws-sdk/client-cognito-identity-provider": "^3.202.0",
-        "@aws-sdk/client-s3": "^3.204.0",
+        "@aws-sdk/client-cloudformation": "^3.485.0",
+        "@aws-sdk/client-cognito-identity-provider": "^3.485.0",
+        "@aws-sdk/client-s3": "^3.485.0",
         "octokit": "^3.1.2"
     },
     "devDependencies": {

services/app-api/package.json

@@ -27,15 +27,15 @@
     },
     "dependencies": {
         "@apollo/gateway": "^2.2.2",
-        "@aws-sdk/client-amplify": "^3.226.0",
-        "@aws-sdk/client-cognito-identity-provider": "^3.226.0",
-        "@aws-sdk/client-lambda": "^3.226.0",
-        "@aws-sdk/client-rds": "^3.226.0",
-        "@aws-sdk/client-s3": "^3.226.0",
-        "@aws-sdk/client-secrets-manager": "^3.226.0",
-        "@aws-sdk/client-ses": "^3.226.0",
-        "@aws-sdk/client-ssm": "^3.226.0",
-        "@aws-sdk/lib-storage": "^3.226.0",
+        "@aws-sdk/client-amplify": "^3.485.0",
+        "@aws-sdk/client-cognito-identity-provider": "^3.485.0",
+        "@aws-sdk/client-lambda": "^3.485.0",
+        "@aws-sdk/client-rds": "^3.485.0",
+        "@aws-sdk/client-s3": "^3.485.0",
+        "@aws-sdk/client-secrets-manager": "^3.485.0",
+        "@aws-sdk/client-ses": "^3.485.0",
+        "@aws-sdk/client-ssm": "^3.485.0",
+        "@aws-sdk/lib-storage": "^3.485.0",
         "@launchdarkly/node-server-sdk": "8.1.1",
         "@opentelemetry/exporter-trace-otlp-http": "^0.45.1",
         "apollo-server-core": "^3.11.1",
@@ -76,7 +76,7 @@
         "@types/uuid": "^9.0.0",
         "@typescript-eslint/eslint-plugin": "^5.6.0",
         "@typescript-eslint/parser": "^6.5.0",
-        "copy-webpack-plugin": "^11.0.0",
+        "copy-webpack-plugin": "^12.0.1",
         "csv-parser": "^3.0.0",
         "eslint": "^8.3.0",
         "eslint-config-prettier": "^9.1.0",

services/app-api/src/domain-models/contractAndRates/convertContractWithRatesToHPP.ts

@@ -22,8 +22,6 @@ import { isEqualData } from '../../resolvers/healthPlanPackage/contractAndRates/
 function convertContractWithRatesToUnlockedHPP(
     contract: ContractType
 ): HealthPlanPackageType | Error {
-    console.info('Attempting to convert contract to health plan package')
-
     // Since drafts come in separate on the Contract type, we push it onto the revisions before converting below
     if (contract.draftRevision) {
         contract.revisions.unshift(contract.draftRevision)

services/app-api/src/domain-models/healthPlanPackage.test.ts

@@ -124,7 +124,9 @@ describe('HealthPlanPackage helpers', () => {
                     stateCode: 'FL' as const,
                     revisions: [],
                 },
-                new Error('No revisions on this submission'),
+                new Error(
+                    'No revisions on this submission with contractID: foo'
+                ),
             ],
         ]
 

services/app-api/src/domain-models/healthPlanPackage.ts

@@ -30,7 +30,9 @@ function packageStatus(
         return 'UNLOCKED'
     }
 
-    return new Error('No revisions on this submission')
+    return new Error(
+        `No revisions on this submission with contractID: ${pkg.id}`
+    )
 }
 
 // submissionSubmittedAt returns the INITIAL submission date. Even if the