Report issues with metadata

[mitchdawson1982]

This PR creates a service to raise issues with metadata on the FMD front end.

Implements

• new /feedback/issue url path
• new report_issue_view
• new ReportIssue model for storing successfully submitted issues
• new ReportIssueForm model form & html template for accepting and validating user input before generating a ReportIssue model instance
• new service module and send_notifcations function for interacting with the notify API
• new variables and secrets for the notify api key(s) and notification template id's
• new tests for forms, models and service

Key Decisions

I have opted to provide the report issue form in a separate view and page via a button on the entity details page.
Some examples I have seen that implement forms on an existing page do so at the bottom, which means the user needs to scroll to the bottom.

I tested placing the form at the top of the entity details page, below the contact section, but it looked cluttered on top of the data. Implementing this way also avoids the need for js to show/hide and validate the form in the front end and allows us to utilise the existing backend methods of form & model validation on submission.

When the report issue form is requested via GET request, we obtain the entity name, full URL and data owner values from the request and store these on the user's session to be used to populate the issue model instance alongside the form values on submission. This avoids the need for creating additional template and form fields to hold these values and placing them back in front of the user. Successfully submitted issues are stored as model instances so that these can be reported on in the future if necessary.

I have implemented a basic integration with the GDS Notify service utilising their Python SDK in which we "fire and forget" notification jobs into the service, logging responses and exceptions as necessary. We could implement a more detailed implementation which periodically polls for message status updates, however, this would then require asynchronous jobs using something such as Celery or Python RQ, and would probably go further than our need at this point but is something we could look at in future.

For further consideration

• Details page button location / style
  

• Location/ Styling of the entity name on the issue form
  

[MatMoore]

Great work, and thanks for the detailed write up.

The only thing that jumps out at me now is the use of data owner, which we know is the wrong role to notify. But if we're OK revisiting that next sprint then we can ignore that for now 👍🏻

[sentry-io]

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

• ‼️ ProgrammingError: relation "feedback_issue" does not exist /feedback/issue View Issue
• ‼️ AttributeError: 'NoneType' object has no attribute 'replace' /feedback/issue View Issue

_{Did you find this useful? React with a 👍 or 👎}