Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate workshop data on past/current memberships to fit new workshop pricing model #2388

Open
maneesha opened this issue Apr 24, 2023 · 3 comments

Comments

@maneesha
Copy link
Contributor

As we implement #2387 we will need to migrate existing data. This migration should be applied as follows. Allowed workshops should match completed workshops.

Generally speaking, any workshop before March 1 2020 (approximate date of COVID global shutdown) happened in-person so we should treat the "allowed" as in-person.

@maneesha
Copy link
Contributor Author

maneesha commented Apr 24, 2023

Example:
Member X was allowed 4 workshops in their membership, term dates August 1 2019 to July 31 2020. They completed 2 inperson workshops in 2019, and 2 online workshops in 2020. The agreement should read as if they were allowed 2 inperson and 2 online for that agreement term.

For unused benefits : If the membership ended before Feb 29 2020, consider the allowed workshops to be in-person workshops. For all memberships after that, consider the allowed workshops to be online workshops.

We will run reports and decide if we want to make manual adjustments from there.

@maneesha
Copy link
Contributor Author

Also include auto-generated comment that describes the number of workshops migrated.

@elichad
Copy link
Contributor

elichad commented Dec 5, 2023

This migration will need to be written manually, making use of Django's RunPython migration step. See migration 0261_migrate_lesson_contribution_to_get_involved for a recent example.

  1. Write the forward step(s)
  2. Write the reverse step(s) - this migration is reversible, so the reverse steps should undo everything that happened in the forward steps
  3. Write tests for both forward and reverse migrations with a variety of pre-existing data. Think about as many edge cases as possible. (follow the format in workshops/tests/test_migrations.py)
  4. Run the migration forward and backward a couple of times on your dev database to ensure it works properly on slightly more realistic data

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants