Update the Erasure Request Email Fulfillment template [#1265]

[pattisdr]

Purpose

Small followup for #1246

Add improvements to the email template that is used to automatically email users and ask them to erase data on behalf of a customer.

Changes

Sample Email Body here:

Note that the copy @conceptualshark suggested has the organization name in it, but we don't have this capability yet - pending #1087

Checklist

• Update CHANGELOG.md file. This is a small followup to the previous PR, no need for a changelog entry.
  • Merge in main so the most recent CHANGELOG.md file is being appended to
  • Add description within the Unreleased section in an appropriate category. Add a new category from the list at the top of the file if the needed one isn't already there.
  • Add a link to this PR at the end of the description with the PR number as the text. example: #1
• Applicable documentation updated (guides, quickstart, postman collections, tutorial, fidesdemo, database diagram.
• If docs updated (select one):
  • documentation complete, or draft/outline provided (tag docs-team to complete/review on this branch)
  • documentation issue created (tag docs-team to complete issue separately)
• Good unit test/integration test coverage
• This PR contains a DB migration. If checked, the reviewer should confirm with the author that the down_revision correctly references the previous migration before merging
• The Run Unsafe PR Checks label has been applied, and checks have passed, if this PR touches any external services

Ticket

Fixes #1265

[sanders41]

It's not part of this PR so I'm not leaving it as part of the review, but a question about <li> Field: <i>{{ field }}</i>, Values: {{ values|join(', ') }} </li>. Could these values contain sensitive/private information we wouldn't want to go through email?

[pattisdr]

Good question @sanders41

I agree we don't want to pass just any data along in the email, but the emailed user does need information to locate the relevant records.

The only fields I am passing to the email itself are values that have been specified as the ones to use to locate records on that collection, in that they should be fields and values that exist in their collection.

Maybe this is a UI concern, making sure the fidesops user knows the consequences of setting up references to an "email" collection.

[pattisdr]

thanks for merging @sanders41