feat: submissions feed reflects events rather than successful audit entries only

[jessicamcinchak]

Currently, the submissions log only displays "successful" events, and it shows a lot of empty space for event types that may not apply to your service.

Now, it reflects events applicable to this service only, including failed ones & retries, like a filtered view of Slack's #planx-notifications channel.

Testing links:

• LDC with payment & "dual processing" https://3153.planx.pizza/lambeth/apply-for-a-lawful-development-certificate/settings/submissions (1 application in log)
• Discretionary service with send to email only https://3153.planx.pizza/testing/quick-test/settings/submissions (3 unique applications in log)

[github-actions]

🤖 Hasura Change Summary compared a subset of table metadata including permissions:

Updated Tables (1)

• public.submission_services_log permissions:

  	insert	select	update	delete
  platformAdmin		➕
  teamEditor		➕

  16 added column permissions

  	insert	select	update
  platformAdmin		➕ created_at ➕ event_id ➕ event_type ➕ flow_id ➕ response ➕ retry ➕ session_id ➕ status
  teamEditor

[jessicamcinchak]

Viewer of submissions in the Editor - v. 2.0

[github-actions]

Removed vultr server and associated DNS entries

[DafyddLlyr]

A few comments on code, a few comments below!

I think we probably want to make our success / failure states more visually obvious. I really like the icons denoting the event types but I feel the green/red distinction is not quite visually strong enough.

A nice usability improvement here would be a copy button next to the session id - super nice though that the click interaction is just on the caret so I can easily copy/paste as-is. I wasn't expecting this from the initial screenshot.

I'm also seeing a slight visual issue with some of the table row styles with a doubled-up bottom border -

Similar to @ianjon3s' comments on Slack, grouping by sessionId might be nice but Hasura doesn't natively support this in queries which I think would mean getting back to the view, or "post-processing" in TS when we have the data - not ideal? Grouping by sessionId also breaks the chronological order of events - also not easily understandable probably? I think I'd favour keeping this as-is for now and awaiting feedback before jumping into changes here - this is a whole lot better than the current submission view and Slack imho 👍

[jessicamcinchak]

This retries logic isn't perfect and assumes we only do 1 automatic retry (max of 2 tries) - but that's true for all our scheduled events currently so let's go with it ! Overall I think a boolean here is a bit easier to reason with officers about than showing raw tries = 2 against both invoked events

[jessicamcinchak]

Slightly tweaking API responses here so they offer a bit more context in the "response" row (will apply to future events only) ✔️

[jessicamcinchak]

This post was helpful for figuring out the "feed" style, and has some good accessibility notes to revisit one day when we're ready to get the Editor certified https://kittygiraudel.com/2024/02/26/css-only-bottom-anchored-scrolling-area/

[ianjon3s]

This is a huge leap forward as a v2! I vote we get it on production and iterate further based on feedback