-
Notifications
You must be signed in to change notification settings - Fork 5
Sprint 17 #543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sprint 17 #543
Conversation
compact commission admins and state admins will want to know how many compact privileges were purchased in a week, who purchased them, which states they were purchased for, and the cost totals so that they can track payments and new practitioners in their state. This adds the needed infrastructure/logic to get the list of transactions for the previous week and generate reports for both compacts and all jurisdictions within those compacts. ### Requirements List - If any compact or jurisdiction in the environment does not have any email addresses listed in their respective reporting list, the transaction reporting lambda will raise an exception, which will fire an alert once a week. This is by design as support teams will need to be notified if reports are not being sent to any recipients. ### Description List - Added transaction reporting system which will send out transaction reports to all jurisdictions as well as the compact - Updated email notification service lambda to handle file attachments ### Testing List - Added tests for python and lambda logic - Verified functionality in sandbox account - Code review Closes #316
### Requirements List - A practitioner account - A read private account - A non read private staff account - All these accounts must be in the same compact - To create a privilege history for the past privileges section: 1) Log in as practitioner user and purchasing a privilege 3) Edit the DB record to back-date it a year 4) Purchase the same privilege again ### Description List - Modified `LicenseeDetail` page to match design - Modified get licensee actions and mutations to work with current API - Modified `LicenseeDashboard` page to match spec - Modified `License` Model to reflect updated API where renewals do not create new licenses or privileges but entries in the history array - Created `LicenseHistoryItem` model - Created / updated all tests as needed - Updated mockAPi ### Testing List - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Code review - Look at the `LicenseeDashboard` page and `LicenseeDetail` page in all screen-sizes and confirm they look good - For the `LicenseeDetail` page look at the page with a read private account and confirm the DOB exists and is populated - For the `LicenseeDetail` page look at the page with a non read private account and confirm the Birth Month-Day exists and is populated Closes #402, #354 --------- Co-authored-by: Dana Stiefel <[email protected]>
### Description List For `Access-Control-Allowed-Origin` headers: - Added specific/multiple origin support in OPTIONS preflight methods - Added specific/multiple origin support for headers in all Lambda API responses - Added specific/ *single* origin support for headers in custom Gateway Responses Note that [*Gateway Responses*](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) are API responses that API Gateway itself returns, when it short-circuits a request before delivering it to our Lambda back-end. These responses are for requests that: - Fail input validation for a POST body or query params, - Are missing a valid authentication token, or - Are missing required scopes for the endpoint. These are specific 400, 401, and 403 responses in specific cases. In those cases, API Gateway has limited support for us customizing the content of the response. That customization does _not_ include calculating a dynamic value based on the request `Origin` header, like we are doing for the other endpoints/responses. Because of this limitation, in the case of these Gateway Responses, we can only support a single, static, value for the allowed origin header or, if we want to support both a proper domain name and `http://localhost:3018` as origins (like in the case of IA's test environment, where we want a common deployed test UI and also for devs to be able to connect their local UI to the shared test environment back-end), we have to still return a `'*'` as allowed origin to support both at once. This limitation does not constrain the production environment or any environments that will have a single allowed origin, since we _can_ set the single origin in the header as a static value. ### Testing List - Code review - Test browser behavior in IA's *test* environment Closes # Closes #165
### Description List - Added DELETE method to /v1/compacts/:compact/staff-users/:userId to delete staff-user's compact permission record - Identified and fixed a bug in the PATCH /v1/compacts/:compact/staff-users/:userId endpoint, if the user does not exist. - Removed API change summary from README since it seemed low value to developers and was not being maintained - Removed OPTIONS methods from openapi spec doc, since they were cluttering up the doc and making it harder to parse. Closes # #475
### Requirements List - ### Description List - Added new optional licenseNumber field to all necessary schemas to support licenseNumber being in license csv upload and in db - Edited test artifacts and tests to reflect change - Updated readme and mock data generation script to reflect change - Updated License model and tests to have licenseNumber and npi fields - Updated Licensee model and tests tests to have licenseNumber field - Updated `LicenseCard` component to display license number if returned ### Testing List Back end: - run tests - Code review - Run the `generate_mock_data` script and upload the resulting csv as a staff user, confirm the resultant data looks as expected - Create / edit a user + license to have the new field, - perform manual confirmation from the front end that this field is now present in that user's license Front end: - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Code review - Look at first Licensee in MockAPI and confirm license number appears in LicenseCard - Once real backend is setup confirm license number appears for in `LicenseCard` in `LicenseeDashboard` (we want to wait until Licensee Detail PR is merged to confirm functionality on LicenseeCard in `LicenseeDetail` page as well Closes #264 --------- Co-authored-by: Dana Stiefel <[email protected]>
Provider need to be able to register in the system to create their accounts and purchase privileges. This adds the needed API endpoint and security infrastructure to support this. The registration process is outlined as follows: 1. A state uploads a license record for a provider, which causes a license record to be created 2. A provider registers through the registration page, specifying their information as recorded on their license. 3. If the provided information matches a license record, and no one has registered for an account under that license, a Cognito account is created and an email invite is sent to them with login information. ### Requirements List - 🚨 🚨 **BEFORE THIS CHANGE CAN BE MERGED!!!** 🚨 🚨CSG must configure Google reCaptcha tokens for both the test and production environments. The instructions for this setup are documented in the README changes as part of this PR. **IF THIS IS MERGED BEFORE THAT SETUP, THE PIPELINE WILL BE BROKEN!** Please ensure that this setup is completed before the final approval on this PR. - As part of this change, we have introduced a new GSI on the provider table, which allows us to match a license record by a person's first and last name. **This GSI will not match against any existing test records in the test environment**, so new test records will need to be populated in the provider table before this functionality can be tested in an environment. ### Description List - Added POST `/v1/provider-users/registration` **public facing** endpoint to allow practitioners to register within the system. - Capturing the home state selection that a practitioner selects when registering with the system. This selection is now used on the backend to determine which license is a practitioner's home state license. - Updated privilege purchase endpoint to use this home state selection record to pick best license. - Update ingest pipeline to use home state selection to choose license to associate with the provider - Returning home state selection record in the provider detail response. ### Testing List - For API configuration changes: CDK tests added/updated in `backend/compact-connect/tests/unit/test_api.py` - Testing in local sandbox environment to verify functionality - Code review Closes #433 --------- Co-authored-by: Justin Frahm <[email protected]>
### Requirements List - A licensee user who's schema is up to date and who has been through the registration process ### Description List - Fixed phone number formatting to work, commented out unused and untested methods, added tests to maintain code coverage standards - Created `PrivilegePurchaseInformationConfirmation` page - Edited routing to put `PrivilegePurchaseInformationConfirmation` page in correct order in privilege purchasing flow - Edited User models, email fields, tests and references to make different email types explicitly distinct - Added `mailingAddress` field to License model to make address relationship explicit - Added phone number field to Licensee model - Added `homeJurisdiction` based off of user registration to `Licensee` model - Added `bestHomeStateLicense` algorithm and `bestHomeStateLicenseMailingAddress` helper functions to Licensee model - Across models deleted fields that were conflicting / misleading vs current API implementation ### Testing List - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Code review - Check out the `PrivilegePurchaseInformationConfirmation` and make sure it looks good in all screen sizes and saves the attestations correctly. - Smoke test pages potentially affected by model changes to confirm I didn't break them worse Screenshots: <img width="1728" alt="Screenshot 2025-02-04 at 9 56 16 AM" src="https://github.com/user-attachments/assets/a683c539-d1a4-402c-9056-564dd956bc5b" /> <img width="1728" alt="Screenshot 2025-02-04 at 9 56 21 AM" src="https://github.com/user-attachments/assets/44bbc278-8593-45da-b51a-f3eddd5ca554" /> Closes #303 --------- Co-authored-by: Dana Stiefel <[email protected]>
### Description List - Added a `POST staff-user/:userId/reinvite` endpoint that will resend an invite email, resetting the user's password if necessary ### Testing List - Code review Closes # closes #476
### Requirements List - New local `.env` variable: - `VUE_APP_RECAPTCHA_KEY` - Use the public key value that corresponds to your environment. If you are using the IA test environment, you can get a key from @jsandoval81 ### Description List - Updated frontend deployment pipelines with recaptcha keys - Updated CSP Lambda to allow calls to Google recpatcha - Updated InputDate component to return empty string instead of null - Added new API call to license API layer & store actions - Updated license API layer to include status code in response - Added registration link to disambiguation Login UI - Added RegisterLicensee page - Updated the license occupation lists ### Testing List - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Code review - Use the mock populate to test that you receive a successful response - This won't result in an email received because it doesn't match any licenses. - You should also be able to make ~4 requests within 15 minutes from the same IP to produce a rate-limit type of error - The error should clear after ~15 minutes - If you're testing against a non-sandbox server environment, you can attempt to use valid info that would successfully locate a license and send an email - If you attempt this, it must be for a license that has not already been registered / claimed - Also note that the email will be the login email if successful, so you may want to use a testing variant of your real email to make things easier
### Description List - Assign a new privilege id on privilege purchase - Reuse privilege id for re-issue of existing privilege - Update API docs - Leverage new logger context manager feature ### Breaking change With this PR, privileges will all be expected to include `privilegeId` in their schema, so any existing privileges (I think there are a total of 0 in CSG environments) will need updating to include one or just be deleted. ### Testing List - Code review Closes #466 Closes #436
CSG has requested that we implement automated monthly transaction reporting. This required several updates to increase the number of transactions that could be handled within a single report. Previously we were passing in the full csv report string to the email-service lambda payload, which was prone to a 6MB file size limit, now we are storing these reports in a compressed zip format in S3, and passing in the S3 key to the email service so it can pull down the file and attach the zip file to the email directly. This adds the needed infrastructure to support monthly reporting in a scaleable manner. ### Requirements List - No new requirements, this change is backwards compatible with the current system ### Description List - Added event bridge rule to trigger transaction reporter lambda on the first day of every month - Added transaction reporting S3 bucket to store compiled csv report files in a compressed format - Update email-notification-service node lambda to pull down report files from S3 - Fix formatting for reporting email body text to support markdown ### Testing List - `yarn test:unit:all` should run without errors or warnings - `yarn serve` should run without errors or warnings - `yarn build` should run without errors or warnings - Python tests added for monthly reporting code verification - Verification of monthly report generation for over 100k transactions in sandbox environment. Closes #493 --------- Co-authored-by: Justin Frahm <[email protected]>
### Requirements List - _None_ ### Description List - Added grecaptcha items to CSP `script-src-elem` ### Testing List - `/backend/compact-connect/lambdas/nodejs` - `yarn lint:csp` - `yarn test:csp` - Code review Closes #529
Now that the frontend has been updated to pass in attestations when purchasing privileges, we are making the field required both on the API endpoint as well as the privilege schema. ### Requirements List - 🚨🚨**BREAKING CHANGE**🚨🚨This change is incompatible with old privilege records that do not have a list of attestations, any invalid privilege records will need to be deleted or updated to include an 'attestations' field. A migration script has been added as part of this PR which devs can run to fix their environments. ### Description List - Update privilege schema to make attestations field required - Update POST purchase API endpoint request schema to make attestations required - Remove flag gating enforcement of attestation versions ### Testing List - For API configuration changes: CDK tests added/updated in `backend/compact-connect/tests/unit/test_api.py` - Code review Closes #425
@jusdino Seems like the below package fails
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good! A few accessibility issues, one potential typo, and one potential bug. @jusdino @landonshumway-ia @ChiefStief @jsandoval81
@jsandoval81 For all of the items you suggested making tickets for, let's add them to "Backlog" (per discussion with Isabel). I'm happy to make them myself, if easier. Just let me know. |
@jlkravitz I got tickets created for all the items we'd discussed. Let me know if I missed anything. |
### Description List - Upgrading backend dependencies while resolving pip-audit finding against cryptography 44.0.0
Fix typo identified in Sprint 17 PR #543
npm audit
andpip audit
) to ensure that there are no vulnerabilities that will be deployed to production (as opposed to vulnerabilities that only have an impact on the development environment)