feat: show submitted applications for a flow in the flow settings

[Mike-Heneghan]

No description provided.

[github-actions]

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

Tracked Tables (1)

• public.applications_summary permissions:

  	insert	select	update	delete
  platformAdmin		➕
  teamEditor		➕

  22 added column permissions

  	insert	select	update
  platformAdmin		➕ amount ➕ payment_date ➕ payment_status ➕ sent_to_bops ➕ sent_to_email ➕ sent_to_uniform ➕ service_slug ➕ session_id ➕ submitted_at ➕ team_slug ➕ user_invited_to_pay
  teamEditor

[github-actions]

Pizza

Deployed ec8a0d9 to https://2867.planx.pizza.

Useful links:

• Editor
• Storybook
• Hasura
• API
• ShareDB

[jessicamcinchak]

Recognise this is still draft, but also know you're about to be away for a long weekend - so a few initial comments on first read through ! Nice to see test coverage and storybook additions here 👍

[jessicamcinchak]

A couple questions about this view:

• I'd expect to see GOV PAY ID, BOPS ID and Uniform IDs exposed for parity with #planx-notifications rather than a yes/no "sent_to" ("yes" maybe still makes sense for send to email, unless we show teams.submission_email address it was sent to?). I think councils currently have a high need for a simple lookup from Planx ID <> integrations ID, rather than needing specific application details like the payment amount exposed here if that makes sense
• It feels very hard to semantically differentiate between applications_summary and submission_services_summary - is there a reason to not simply update submission_services_summary directly to include these additional columns?

[Mike-Heneghan]

Data Exposed:

• That's a very good point regarding GOV PAY ID, BOPS ID and Uniform IDs.
• I hadn't properly parsed #planx-notifications so was just seeing what I thought were PlanX session ids 🤦
• I'll get this updated 👍
• Do we still want payment details other than the id, I think it was mentioned in the ticket but I got the wrong end of the stick?

[Mike-Heneghan]

DB View:

• I had originally used submission_services_summary but as that's exposed via Metabase and in my understanding would have the potential to be more public facing I thought I better hide the extra info like payment details
• I hadn't added it but I thought there might be a chance we'd add more explicit PII like email or name to this view depending on teamEditors would use it?
• If that's not the case and the data we'd have here wouldn't be sensitive then I think it could be added to the existing view 👍

[jessicamcinchak]

I'd vote we aim for feature parity with the information in #planx-notifications which is not currently PII and would therefore let us use the same view if it makes sense format wise.

As I understand it this is meant to sort of be more a receipt of pay & send events, and it's the back office systems responsibility to display actual application details. If further requests come from POs, we could of course re-evaluate.

What I think the data we want is:

• session id
• payment_requests.status, govpay_payment_id, created_at (amount not necessary)
• bops_applications.bops_id (maybe destination_url to differentiate between v1 & v2 recently)
• uniform_applications.idox_submission_id (submission_reference = session id so can be omitted)
• email_applications.recipient
• submission timestamp for each applicable destination

That would all be considered non-PII as it's just how various identifiers link up.

There's one consideration with my proposal though that I'm not sure your original data structure accounted for: there will be many payment_requests & bops_applications per each session and I think we want to show each of them, not just the latest. This might make a case for a separate view or just a note to group by session_id if able to use exisitng submission_services_summary?

Does that help at all?

[Mike-Heneghan]

This is super helpful thanks Jess!

I'll have a look into adding this to the view and I could maybe create arrays of payment_requests and bops_applications to maintain the expectation of one row in submission_services_summary per session_id 🤔

[jessicamcinchak]

Arrays make sense if easy enough to work with on the frontend - I'd imagine GraphQL should be good for this 👍

And just to be totally clear - any pay or send destination can technically be many events to one session id because of re-submissions, but payments & BOPS are just the two that happen most often/intentionally !

[Mike-Heneghan]

I've added a PR to update the submission_services_summary view to hopefully expose the data as discussed: #2879

[Mike-Heneghan]

Recognise this is still draft, but also know you're about to be away for a long weekend - so a few initial comments on first read through ! Nice to see test coverage and storybook additions here 👍

Thanks Jess, I really appreciate it!

[Mike-Heneghan]

Closing as this has been reworked as per feedback and split into smaller PRs.