[Admin UI] FE - Ability to input a reason for denying a Subject Request

[adriaaaa]

Is your feature request related to a specific problem?

According to many privacy regulations, organizations have the right to deny a request if, for example, the organization is subject to a State or Union law that restricts it's ability to fulfill a request. Organizations are instructed to record why they denied the request. The scope of this issue is to provide the ability for an admin user to be able to input a denial reason when denying a subject request.

Describe the solution you'd like

1. A Fidesops UI user must have the ability to enter a reason when denying a request
   -- affiliated privilege - "Subject Request Management"
   -- There is a wide array of reasons why an organization may deny a request. For ease of delivery, we could provide a free text box for the user to enter in the reason why they are denying this request.
   -- In terms of number of characters to be expected for a denial reason, it looks like most denial reasons are around 200 characters, but we should allow buffer here.
   -- Denial reasons do not have to be searchable (for now)

Scenarios

Scenario	Expected Behavior
Denying a SR
User clicks on a New Subject Request and selects Deny	User should be presented with a modal to enter in a denial reason
User clicks on a New Subject Request and selects Deny → selects “Cancel”	Modal disappears, SR should remain in “New” state
User clicks on a New Subject Request and selects Deny → enters a denial reason → selects “Confirm”	Modal stays present until the request is finished, then the modal will close. SR should transition to a “Denied” state. Denial reason is saved in the backend. Fidesops should log that a user denied the request in it’s audit logs. The user that denied the request should be captured as the “reviewer” in the UI
User clicks on a New Subject Request and selects Deny → enters a denial reason → selects “Cancel”	Modal disappears, SR should remain in “New” stateDenial reason text should be cleared
User clicks on a New Subject Request and selects Deny → enters a denial reason → selects “confirm” → clicks outside of the modal or presses escape before the request can finish	Modal disappears. SR will remain in the “New” state until the action is completed in the backend. Once it’s completed, the SR should transition to the “Denied” state. If the user tries to deny the request again, the modal should appear with the previously written test
Approving a SR
User clicks on a New Subject Request and selects Approve	SR should transition to a “In Progress” state. The UI should no longer show the options for approve/deny since it’s in a different state. Fidesops should initiate processing the request through the connected data stores. Fidesops should log that a user approved the request in it’s audit logs. The user that approved the request should be captured as the “reviewer” in the UI

Additional context

Mockups

[seanpreston]

As discussed previously, this is best hooked into a more formal events log for Fidesops, so that we can track everything that happens in the system for audit purposes, so ideally let's build any solution here around that concept.