070d067709
# Description This PR integrates screening API verifications into staging. There's 2 commits: * The earliest one, it just copy-pastes the strategy followed by edeposit and adapts it to fit screening API case, which is simpler. Note here that the schema entries contain a low number of tests. This is because we only have 7 records in production - and these seem fake anyway :) - so it's complex to extrapolate. Those I could extrapolate (NoFlags/Flagged) I'm taking from the data transformation within the PBI report. * The last commit, it's just a DRY. It handles the deduplication logic for cosmos db in a macro, and I applied it on both the screening API and the edeposit verifications. Works well from my POV. Since you guys are far more knowledgeable on APIs scope, I'll let you take a close look in case I missed something. # Checklist - [X] The edited models and dependants run properly with production data. - [ ] The edited models are sufficiently documented. **I guess it can be improved, waiting for your comments here** - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [ ] I've picked the right materialization for the affected models. **Used default coming from stg_edeposit__verifications** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20127 |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitkeep | ||
| business_kpis_configuration.sql | ||
| calculate_safe_relative_increment.sql | ||
| cosmos_db_utils.sql | ||
| generate_schema_name.sql | ||
| generate_stripe_sources_unioned_select.sql | ||
| is_date_before_previous_month.sql | ||
| user_migration_configuration.sql | ||