-
Notifications
You must be signed in to change notification settings - Fork 1
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
Email Notifications [mimics PR branch] #141
base: main
Are you sure you want to change the base?
Conversation
…require first running a -target run
It took me an undue amount of time to get the |
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.
code LGTM but couple of comments:
- can you test the identity provider flows to make sure the account creation emails are still sending properly since we made changes to identity provider
- i think i spotted a bug in the sesv2_email_identity resource where we are passing in the dash_domain for the email_identity
potentially out of scope for this PR, but the identity provider and notifications features are sufficiently complex that i think we should add some e2e testing (in template-only-ci-infra.yml) for those to prevent regressions, maybe we can do that in a later PR and just be ok with manual testing for now
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.
I think this is ready once it's been tested. Just some nits
infra/modules/notifications-email-domain/resources/variables.tf
Outdated
Show resolved
Hide resolved
🚀 |
## Ticket Resolves navapbc/platform-test#140 ## Changes - Apply defaults to _"sender email"_ and _"reply to email"_ - Propagate `enable_notifications` throughout the configuration as it is now being used - Create the following modules: - `notifications_email_domain`, meant to be deployed from `main`, which deploys an DNS records in service of validating an email identity - `existing_notifications_email_domain`, meant be deployed from temporary environments, which uses data resources to pull from `notifications_email_domain` - `notifications`, used in both of the above cases, which deploys an AWS Pinpoint application capable of sending emails - Creates notification resources! ## Usage Context Grants.gov plans to use this for "transactional" emails, eg. password resets, status updates, etc. ## Context for reviewers This will be followed up by: - #789 - #778 - #777 ## Testing See navapbc/platform-test#141, specifically navapbc/platform-test#141 (comment)
Ticket
See also: #140
Resolves navapbc/template-infra#690
Changes
Creates
infra/app/service/notifications.tf
with the email notifications configurationCreates
infra/app/service/identity_provider.tf
to mirror the above, entirely becauseinfra/app/service/main.tf
was getting too longAdds a pair of
notifications
andexisting_notifications
, which work on the main branch and PR branches respectively. Thenotifications
module creates the shared resources for an environment's SES configuration (ex. DNS records), whereasexisting_notifications
requests those shared resources. Then both environments usenotifications_app
which creates the email notifications client application (AWS Pinpoint) that applications will use to send emails.Context for reviewers
You can test sending an email here: https://us-east-1.console.aws.amazon.com/pinpoint/home?region=us-east-1#/apps/e547b32682c34c5da1e7e18994794ca9/direct ...just... don't send emails to random 3rd parties as me 😆
Testing
Preview environment