feat: create submission_services_log view
#3144
Conversation
|
🤖 Hasura Change Summary compared a subset of table metadata including permissions: Tracked Tables (1) |
| select | ||
| session_id, | ||
| payment_id::text as event_id, | ||
| 'Pay' as event_type, |
There was a problem hiding this comment.
In the future we may want to expand this to more clearly distinguish 'Pay' & 'Invite to Pay' - but we know the latter is rarely used currently and all payment attempts will be captured here regardless of method.
| created_at | ||
| from payment_status | ||
| where status != 'created' | ||
| and created_at >= '2024-01-01' |
There was a problem hiding this comment.
Is there any reason to query & display submissions prior to January 2024? This filter gives us a bit more consistency in event formatting & we could always look up submissions outside this timeframe on request.
There was a problem hiding this comment.
Totally on board with keeping this filter in place - makes a whole lot of sense.
| seil.created_at | ||
| from hdb_catalog.hdb_scheduled_events se | ||
| left join hdb_catalog.hdb_scheduled_event_invocation_logs seil on seil.event_id = se.id | ||
| where se.webhook_conf::text not like '%email/%' |
There was a problem hiding this comment.
I'm filtering out email events (reminders, confirmations, saves etc) - they'd be easy to add in the future if we want, but let's keep straightforward for now 👍
| ae.* | ||
| FROM all_events ae | ||
| left join public.lowcal_sessions ls on ls.id = ae.session_id | ||
| WHERE ls.flow_id is not null |
There was a problem hiding this comment.
flow_id is null in older cases where we used to create send events on /draft or /preview routes - this filters those out & there's been a fix in place to not create events on those routes at all anymore.
There was a problem hiding this comment.
Alternatively, could we remove those records which should not have been created?
There was a problem hiding this comment.
Event logs will simply be cleaned up by scheduled data sanitation, right? Personally would like to avoid a manual removal of records - they were arguably created "correctly" at the time, so I don't see an issue with keeping the audit history of them!
|
Removed vultr server and associated DNS entries |
| created_at | ||
| from payment_status | ||
| where status != 'created' | ||
| and created_at >= '2024-01-01' |
There was a problem hiding this comment.
Totally on board with keeping this filter in place - makes a whole lot of sense.
| ae.* | ||
| FROM all_events ae | ||
| left join public.lowcal_sessions ls on ls.id = ae.session_id | ||
| WHERE ls.flow_id is not null |
There was a problem hiding this comment.
Alternatively, could we remove those records which should not have been created?
Creates a new view of submission & pay events - now exposing successful and failed events - more similar to what we log in
#planx-notifications.Here's a snippet of what this looks like running against an environment with submissions:
Next steps: