POA decline email

[opticbob]

Summary

• This work is behind a feature toggle (flipper): YES
• (Summarize the changes that have been made to the platform): This PR adds a POA request notification model used to track emails sent in the POA request lifecycle, it adds a decline email sent when a representative declines a POA request, and adds the notification tracking to the existing digital submit confirmation email.
• (If bug, how to reproduce)
• (What is the solution, why is this the solution?): We needed the decline email and wanted a way to track all of the POA request emails sent.
• (Which team do you work for, does your team own the maintenance of this component?): FAR/ARM. I'm not sure if we will own the future maintenance or if that will transfer to the ART team.
• (If introducing a flipper, what is the success criteria being targeted?)

Related issue(s)

• Digital Submit Decline Email Notification in VA Notify Staging va.gov-team#102754
• Link to previous change of the code/bug (if applicable)
• Link to epic if not included in ticket

Testing done

• New code is covered by unit tests
• Describe what the old behavior was prior to the change: Declining wouldn't send an email.
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing: Declining a POA request in the Accredited Representative Portal should send a decline email to the veteran who made the request.
• If this work is behind a flipper:
  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas) Most of the changes are in the AccreditedRepresentativePortal module. There are a few changes to Settings for sending the email, and a small change to the RepresentationManagement module to track the submit confirmation email.

Acceptance criteria

• I updated & added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

[nihil2501]

@opticbob

I don't know if it's an issue to place PII in Sidekiq job arguments (they show up in Sidekiq UI for example and potentially get sent to DD logs).

But overall, that idea of capturing the entity in a PowerOfAttorneyRequestNotification and then enqueuing work based on just the ID of that entity applies here too.

The notification record itself can know about the claimant's email, and also the email template that it uses.

notification.claimant_email # or `recipient_email`?, chain calls or introduce delegation
notification.email_template

Email template can be based on the type of notification. STI is an option there or just a switch statement if the variation in behavior is really simplistic.

[opticbob]

I didn't think it was an issue to send the email address in the arguments. That matches the implementation of the VANotify::EmailJob that is widespread in the app and that is the pattern I worked from.

I'll go ahead and make the change and go with a case statement in the notification model, there are only four cases to keep track of.