wip for the big completeness monster

models/intermediate/core/int_core__verification_request_completeness.sql

@@ -0,0 +1,65 @@
+/*
+Welcome, fellow modeller.
+
+This table exists because, surprisingly, telling whether a guest journey (AKA 
+Verification Request) is completed or not is rather complex.
+
+This model is built mostly to encapsulate the chaos necessary to determine 
+this. With the output of this model, we can simply join the final result to
+the main Verification Request table and enjoy having this abstracted away.
+
+The original logic was inspired by the SQL Server function 
+`GetVerificationProgress` that I borrowed from the backend. You can find its
+code here: 
+https://guardhog.visualstudio.com/Superhog/_git/superhog-mono-app?path=/Guardhog.Data/Functions/GetVerificationProgress/202305021429044_GetVerificationProgress.cs
+*/
+/*
+As for the general logic, so that the monster below makes some slight sense:
+- We have three possible outcomes: Not Started, Action Required and Complete.
+- Not Started records are easy to spot: if there is no associated Guest or 
+  VerificationSet, the Guest Journey wasn't even started.
+- Action Required are the tricky bits:
+    - On one hand, if the VerificationSet contains VerificationTypes 
+      `PaymentValidation` or `Contract`, those need to be completed 
+      WITHIN THE SAME VERIFICATION REQUEST.
+    - On the other hand, any other Verification Types that are required can be
+      completed on the same VerificationRequest OR IN ANOTHER ONE (as long as
+      the guest user is the same)
+    - So, to spot Action Required records, we:
+        - Check if `PaymentValidation` or `Contract` were required and not 
+          completed in the same VR.
+        - Check if any other required VerificationType were required and not 
+          completed on any other VR with the same user.
+        - Take into account the nuanced meaning of "not completed": it can be 
+          either that the Verification exists but the VerificationState is 
+          different than 1 (Confirmed), OR that there isn't even a created 
+          Verification.
+    - Finally, whatever doesn't fall into Not Started or Action Required, 
+      is considered Complete.
+*/
+with
+    stg_core__verification_request as (
+        select * from {{ ref("stg_core__verification_request") }}
+    ),
+    stg_core__verification as (select * from {{ ref("stg_core__verification") }}),
+    stg_core__verification_set_to_verification_type as (
+        select * from {{ ref("stg_core__verification_set_to_verification_type") }}
+    ),
+    expected_verifications as (
+        select *
+        from stg_core__verification_set_to_verification_type vstvt
+        left join
+            stg_core__verification_request vr
+            on vstvt.id_verification_set = vr.id_verification_set
+    )
+# ## THE WORK IN PROGRESS CODE FOR THIS IS IN DBEAVER SCRIPT 22
+select
+    vr.id_verification_request,
+    case
+        when vr.id_user_guest is null
+        then 'Not Started'
+        when vr.id_verification_set is null
+        then 'Not Started'
+        else 'Complete'
+    end as verification_request_status
+from stg_core__verification_request vr