Add missing migrations

[stsewd]

There are some missing migrations on the project, this make a little difficult to isolate migrations for other recent changes.

[humitos]

Good! I noticed this some time ago and I wasn't sure why this was happening. Do you know why these migrations are needed?

I supposed that it could be some help_text that changed or choices so a new migration is needed but in the migration files it seems there are CreateModel calls. So, I'm confused. How the project could work without those models created? Aren't those models necessary for the project? Should we remove them?

[safwanrahman]

So this models were added by #2764
@agjohnson Do you have any idea why the migration was not added? and how that is working now in production?

[stsewd]

@humitos @safwanrahman maybe something to do with the python manage.py loaddata test_data step (just trying to guess here)?

And I'm not sure about the production db.

[humitos]

@stsewd the loaddata command doesn't affect the models, it just add data to the database without touching its structure. So, that shouldn't be the issue.

[humitos]

@ericholscher can you take a quick look at this PR? This is causing problems in other PRs to generate the proper migrations files.

[agjohnson]

I believe most of these are due to linting and other cleanup, but the integration proxy models might be either a missed migration or a difference in django versions or something? I believe we need those migrations either way.

I will block on the migration names. As I usually bring up in migration PRs, I prefer migrations to be named, not autonamed. If there was a way to auto enforce this, I'd be 👍 on that as well.

[stsewd]

but the integration proxy models might be either a missed migration or a difference in django versions or something?

@agjohnson I did a grep and didn't find any previous migration about that models on the project :/

I updated the names, I'm not sure if I chosen the more descriptive name for some migrations, let me know if you want me to change some names.

[ericholscher]

This looks good, and will remove the need to run migration warnings locally. Managing migration names is hard, but I'd say we merge it this week along w/ our other "cleanup" PR's, so we can test it locally and then deploy next week.

Will wait on @agjohnson's re-review to merge.

[humitos]

but the integration proxy models might be either a missed migration or a difference in django versions or something? I believe we need those migrations either way.

I'd say that it's because the proxy = True. There is a better explanation here: https://stackoverflow.com/questions/37988914/why-does-django-create-migration-files-for-proxy-models

I just left some suggestions regarding the naming of the files.

[humitos]

Name suggestion: 0002_alter_choices_in_level_model.py

[humitos]

Name suggestion: 0003_create_proxy_webhook_models.py

[humitos]

Name suggestion: 0024_alter_and_project_models.py

[stsewd]

...alter_and domain and project, right?

[ericholscher]

This is outdated. Closing this, we should just run this right before doing a deploy, since any PR will likely conflict or go stale.