Merge branch 'main' into stvnrlly-paperless-api

docs/data-storage.md

@@ -0,0 +1,70 @@
+Data Storage Policies & Procedures
+==================================
+
+
+Potential PII Locations
+-----------------------
+
+### Tables
+
+#### users<sup>1</sup>
+
+* name
+* email_address
+* mobile_number
+
+#### invited_users<sup>1</sup>
+
+* email_address
+
+#### invited_organization_users<sup>1</sup>
+
+* email_address
+
+#### jobs
+
+No db data is PII, but each job has a csv file in s3 containing phone numbers and personalization data.
+
+#### notifications
+
+* to
+* normalized_to
+* _personalization<sup>2</sup>
+* phone_prefix<sup>3</sup>
+
+#### notification_history
+
+* phone_prefix<sup>3</sup>
+
+#### inbound_sms
+
+* content<sup>2</sup>
+* user_number
+
+#### events
+
+* data (contains user IP addresses)<sup>1</sup>
+
+### Notes
+
+#### Note 1.
+
+Users and invited users are Federal, State, or Local government employees or contractors. Members of the general public are _not_ users of the system
+
+#### Note 2.
+
+Field-level encryption is used on these fields.
+
+Details on encryption schemes and algorithms can be found in [SC-28(1)](https://github.com/GSA/us-notify-compliance/blob/main/dist/system-security-plans/lato/sc-28.1.md)
+
+#### Note 3.
+
+Probably not PII, this is the country code of the phone.
+
+
+Data Retention Policy
+---------------------
+
+Seven (7) days by default. Each service can be set with a custom policy via `ServiceDataRetention` by a Platform Admin. The `ServiceDataRetention` setting applies per-service and per-message type and controls both entries in the `notifications` table as well as `csv` contact files uploaded to s3
+
+Data cleanup is controlled by several tasks in the `nightly_tasks.py` file, kicked off by Celery Beat.

docs/deploying.md

@@ -42,7 +42,10 @@ for experimenting with infrastructure changes without going through the full CI/
 Rules for use:
 
 1. Ensure that no other developer is using the environment, as there is nothing stopping changes from overwriting each other.
-1. Clean up services you create when you are done. `terraform destroy` from within the `terraform/sandbox` directory should do it.
+1. Clean up when you are done: 
+    - `terraform destroy` from within the `terraform/sandbox` directory will take care of the provisioned services
+    - Delete the apps and routes shown in `cf apps` by running `cf delete APP_NAME -r`
+    - Delete the space deployers still shown in `cf services` by running `terraform/destroy_service_account.sh -s notify-sandbox -u <space-deployer>`
 
 ### Deploying to the sandbox
 

docs/infra-overview.md

@@ -22,16 +22,21 @@ In SNS, we have 3 topics for SMS receipts. These are not currently functional, s
 
 Through Pinpoint, the API needs at least one number so that the application itself can send SMS for authentication codes.
 
-The API also has access to AWS S3 buckets for storing CSVs of messages and contact lists. It does not access a third S3 bucket that stores agency logos. 
+The API also has access to AWS S3 buckets for storing CSVs of messages and contact lists. It does not access a third S3 bucket that stores agency logos.
 
 We may be able to provision these services through cloud.gov, as well. In addition to [s3 support](https://cloud.gov/docs/services/s3/), there is [an SES brokerpak](https://github.com/GSA-TTS/datagov-brokerpak-smtp) and work on an SNS brokerpak.
 
+## New Relic
+
+We are using [New Relic](https://one.newrelic.com/nr1-core?account=3389907) for application monitoring and error reporting. When requesting access to New Relic, ask to be added to the Benefits-Studio subaccount.
+
 ## Onboarding
 
 - [ ] Join [the GSA GitHub org](https://github.com/GSA/GitHub-Administration#join-the-gsa-organization)
 - [ ] Get permissions for the repos
 - [ ] Get access to the cloud.gov org && space
 - [ ] Get [access to AWS](https://handbook.tts.gsa.gov/launching-software/infrastructure/#cloud-service-provider-csp-sandbox-accounts), if necessary
+- [ ] Get [access to New Relic](https://handbook.tts.gsa.gov/tools/new-relic/#how-do-i-get-access-to-new-relic), if necessary
 - [ ] Pull down creds from cloud.gov and create the local .env file
 - [ ] Do stuff!
 
@@ -54,4 +59,4 @@ TODO: create env vars for these origin and destination email addresses for the r
 6. Go to SNS console for \$AWS_PINPOINT_REGION, look at lefthand sidebar under "Mobile" and go to "Text Messaging (SMS)"
 7. Scroll down to "Sandbox destination phone numbers" and tap "Add phone number" then follow the steps to verify (you'll need to be able to retrieve a code sent to each number)
 
-At this point, you _should_ be able to complete both the email and phone verification steps of the Notify user sign up process! 🎉
+At this point, you _should_ be able to complete both the email and phone verification steps of the Notify user sign up process! 🎉

docs/openapi.yml

@@ -570,7 +570,7 @@ paths:
                 reference:
                   type: string
             example:
-              phone_number: "5558675309"
+              phone_number: "2028675309"
               template_id: "85b58733-7ebf-494e-bee2-a21a4ce17d58"
               personalisation:
                 variable: "value"

docs/system-description.md

@@ -0,0 +1,38 @@
+US Notify
+=========
+
+System Description
+------------------
+
+US Notify is a service being developed by the TTS Public Benefits Studio to increase the availability of
+SMS and email notifications to Federal, State, and Local Benefits agencies.
+
+Agencies that sign up will be able to create and use personalized message templates for sending
+notifications to members of the public regarding their benefits. These could include reminders
+about upcoming enrollment deadlines and tasks, or information about upcoming appointments, events,
+or services.
+
+The templates are sent by the agency using one of two methods:
+
+* using the US Notify API to send a message to a given recipient with given personalization values
+* using the US Notify website to upload a CSV file of recipients and their personalization values, one row per message
+
+### Environment
+
+US Notify is comprised of two applications both running on cloud.gov:
+
+* Admin, a Flask website running on the python_buildpack which hosts agency user-facing UI
+* API, a Flask application running on the python_buildpack hosting the US Notify API
+
+US Notify utilizes several cloud.gov-provided services:
+
+* S3 buckets for temporary file storage
+* Elasticache (redis) for cacheing data and enqueueing background tasks
+* RDS (PostgreSQL) for system data storage
+
+US Notify also provisions and uses two AWS services via a [supplemental service broker](https://github.com/GSA/datagov-ssb):
+
+* [SNS](https://aws.amazon.com/sns/) for sending SMS messages
+* [SES](https://aws.amazon.com/ses/) for sending email messages
+
+For further details of the system and how it connects to supporting services, see the [application boundary diagram](https://github.com/GSA/us-notify-compliance/blob/main/diagrams/rendered/apps/application.boundary.png)