Personalisation Redaction: Redact notifications during deserialization

[kalbfled]

User Story - Business Need

• [ ] Ticket is understood, and QA has been contacted (if the ticket has a QA label).

User Story(ies)

As a VA service, I want not to see PII when I GET a notification So that everybody remains in compliance with all applicable laws and VA policies.

As a Notify developer, I want not to decrypt personalization data for notifications created from templates with redact_personalisation set to True So that everybody remains in compliance with all applicable laws and VA policies.

Additional Info and Resources

As currently implemented, notification personalization data is encrypted for storage in the database and decrypted during the deserialization process used to GET a notification.

The TemplateBase class has a boolean redact_personalisation attribute that doesn't seem to be used or is not correctly implemented.

The desired behavior is that the response to notification GET and POST requests contain "\<redacted>" for all personalization values when the template used to create the notification has "redact_personalisation" set to True. This should not affect what's actually stored in the database.

Engineering Checklist

Off-track awareness - if the engineering work seems like it's going to take more than 3 days, please raise to the team immediately. Our assumption is engineering gets 3 pts and QA gets 2 pts.

I recommend creating a new file, tests/app/v2/notifications/test_notification_redaction.py, for unit tests rather than adding to the existing files.

• Write new unit tests first. The response from the following routes should display "\<redacted>" for all personalized values when redact_personalisaiton is True and the actual value when redact_personalisation is False:
  • [ ] POST /v2/notifications/sms (with phone number and recipient ID)
  • [ ] POST /v2/notifications/email (with e-mail address and recipient ID)
  • [ ] GET /v2/notifications (for an e-mail notification)
  • [ ] GET /v2/notifications (for a SMS notification)
• Implement the behavior codified by the tests.
  • [ ] POST /v2/notifications/sms (with phone number and recipient ID)
  • [ ] POST /v2/notifications/email (with e-mail address and recipient ID)
  • [ ] GET /v2/notifications (for an e-mail notification)
  • [ ] GET /v2/notifications (for a SMS notification)
• [ ] update swagger to include the redact_personalisation for post /service/(service_id}/template
• [ ] update swagger to include the redact_personalisation for update /service/(service_id}/template/{template_id}
• [ ] Update the Slide deck with the key win and a demo slide

Acceptance Criteria

• [ ] New code does not use any dao method other than those present in existing fixtures. Where convenient during refactoring, remove existing uses of dao code.
• [ ] Manual and unit test verification of all intended redactions.

QA Considerations

For QA to populate. Leave blank if QA is not applicable on this ticket.

• [ ] TBD based on convo with dev when ticket is picked up

Out of Scope

• Only modify v2 routes. Do not change v1 (in app/notifications/) routes.
• Do not attempt to determine if any particular personalized value is PII. Redact everything or nothing.
• Do not worry about redacted letters, which is functionality not in use.
• Do not attempt to sanitize the database once a notification reaches a final state. We will handle that in other tickets.

[mjones-oddball]

Hey team! Please add your planning poker estimate with Zenhub @babyjunior56 @cris-oddball @EvanParish @k-macmillan @kalbfled @ldraney @nikolai-efimov

[k-macmillan]

okay to keep