cf1d6e28cc
# Description This PR fixes the New Dash migration issue that happened on September 10th 2024. In this migration, users were directly assigned the claim of KygMvp that does not contain a date value. We were using a default hardcode of the first MVP migration, thus in DWH all users have been considered to be migrated late July instead of splitting the first 22 in late July and the ~200 others in September. The issue lies in the fact that users have configured a ProductBundle and can have Bookings with ProductBundle BEFORE the migration date, which greatly breaks the logic of a migration monitoring. Changes: * New migration phase added based on the claim MvpMigratedUser, that Ben created on Friday 13th * Adaptation of the code in int_core__user_migration to detect if the claim_value (a text field) has a date or not. If so, use that date as long as it's equal or greater than the deployment date, if not use the deployment date. If the claim does not contain a date, use the deployment date (this is the case for the first true 22 migrated users) I checked that volumes now look correct with this fix. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [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. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20773 |
||
|---|---|---|
| .. | ||
| tests | ||
| .gitkeep | ||
| business_kpis_configuration.sql | ||
| calculate_safe_relative_increment.sql | ||
| generate_schema_name.sql | ||
| generate_stripe_sources_unioned_select.sql | ||
| is_date_before_previous_month.sql | ||
| user_migration_configuration.sql | ||