counterweight/data-dwh-dbt-project
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merged PR 3396: Changes claims and logic to consider user is in new dash

Browse source 
# Description

Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic.

If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc)

If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash.

The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work.

# Checklist

- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY**
- [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.

Changes claims and logic to consider user is in new dash. Downstream propagation included

Related work items: #23457
This commit is contained in:
Oriol Roqué Paniagua 2024-10-31 15:45:28 +00:00
parent bf2310301a
commit 03797827a4
7 changed files with 145 additions and 195 deletions
Download patch file Download diff file Expand all files Collapse all files

49
macros/user_migration_configuration.sql
View file

@ -1,49 +0,0 @@
/*
Macro: get_new_dash_migration_phases_configuration
Provides a general configuration for the different phases of the
New Dash migration. Each phase is identifiable via a phase_name,
that is the "expected display" for users. The assumption is that
each user migration is identified via claim_type. Lastly, we
apply here a hardcode of when the deployment was carried out.
Important note: if a user migrates once a phase has started, we
will not be able to tell when that happened. However, it is likely
that other indicators will provide an estimate. For example:
The migration A happens on 1st July 2024.
User A is migrated on 1st July 2024 (as expected)
User B is migrated on 10th July 2024 (not expected)
It is likely that User B won't have Bookings from new dash
until it's migrated. So this migration date should be considered
as a hard, lower-limit of dates.
If a user satisfies more than one valid claims, in order to ensure
that the good date is considered we use the claim_enforcement_priority
value to force that a certain claim type will have precedence over
another. The lower the value, the more priority.
*/
{% macro get_new_dash_migration_phases_config() %}
{% set migration_phases = [
{
"phase_name": "MVP",
"claim_type": "KYGMVP",
"default_deployment_date": "2024-07-30",
"claim_enforcement_priority": 2,
},
{
"phase_name": "MVP",
"claim_type": "MVPMIGRATEDUSER",
"default_deployment_date": "2024-09-10",
"claim_enforcement_priority": 1,
},
{
"phase_name": "V2",
"claim_type": "KYGMOVEDATE",
"default_deployment_date": "2024-10-08",
"claim_enforcement_priority": 0,
},
] %}
{{ return(migration_phases) }}
{% endmacro %}