Upgrade to Django 2.2.9

[humitos]

Group of changes are divided into commits:

• update where to import resolve from
• use on_delete=models.CASCADE to all those ForeignKey and OneToOneField in models and migrations files
• remove view_ permissions manually created by us since they are automatically created since Django 2.1
• upgrade django in requirements

NOTE: I tried using squashmigrations to avoid modifying migration files but it's way more complicated and since we are just forcing the default value to migrations, I do not think it's a problem

Closes #5058

[ericholscher]

Seems reasonable. Is there any specific testing we need to do on this locally to test it?

[humitos]

My main concern is about running the migrations (since they are modified) on a prod-like database. It should not be a problem because we are making the default value explicit only. However, that would be a good test.

Another thing to verify is that creating an environment from scratch (without any migration ran yet) it does work.

Locally, I did some QA and I didn't find anything strange/wrong.

On the other hand, I'm blocking this PR since we need to make the merge of other dependencies (-ext and corporate) together with this one. Aside from that, we can test this PR without problems in .org.

[stsewd]

use on_delete=models.CASCADE to all those ForeignKey and OneToOneField in models and migrations files

Was there a problem with just creating a new migration?

[humitos]

Was there a problem with just creating a new migration?

This is not possible because when running the old migrations file it will fail because there is no on_delete value. It's possible to squash them all, but it's a lot more work.

[davidfischer]

This is not possible because when running the old migrations file it will fail because there is no on_delete value.

I hadn't considered this. That's pretty unfortunate, but I think the way you did it is probably best.

Note: this is what the 1.9 release notes suggest as well.

[davidfischer]

I'm not sure about the redirects failures in CI but otherwise this looks good. I put this through the paces of running a full build through docker including verifying the output. It looked good and ran well!

My main concern is about running the migrations (since they are modified) on a prod-like database.

No migrations are "run" as part of this since you are just modifying past migrations. I did run the migrations from both my current database and from scratch just to be sure. It ran fine.

[stsewd]

I have update this PR with

• Use newest version of django 2.2.x
• Accept *args and **kwargs from the 404 view

We are setting this view as handler404 on tests,
this view expects an extra arg (exception)

https://docs.djangoproject.com/en/2.2/ref/views/#the-404-page-not-found-view

(not sure why it worked before)

• Add the eric fixture to all tests using test_data, since test_data.json contains references to eric.json and django checks for integrity in sqlite.

[stsewd]

There are some migrations from django that we need to run

admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [ ] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [ ] 0009_alter_user_last_name_max_length
 [ ] 0010_alter_group_name_max_length
 [ ] 0011_update_proxy_permissions

[stsewd]

I still want to test this a little more, but looks ok for now

[humitos]

I think this is not correct. The function definition is:

 defaults.page_not_found(request, exception, template_name='404.html')

There is no *args or **kwargs on it.

What we need to change instead is

readthedocs.org/readthedocs/proxito/tests/handler_404_urls.py

Lines 24 to 31 in 3f6abb5

	def inner_view(request, *args, **kwargs):
	return view_func(
	request,
	*args,
	proxito_path=request.get_full_path(),
	**kwargs,
	)
	return inner_view

if anything.

[stsewd]

I fixed this #6494 (comment) in a commit, but I push it when github was having problems, so it doesn't appear here...

[stsewd]

Had to force push the last commit to make it appear : D