Migration auth.0011_update_proxy_permissions fails for models recreated as a proxy.

[Julien Enselme]

I am trying to update my project to Django 2.2. When I launch python manage.py migrate, I get this error message when migration auth.0011_update_proxy_permissions is applying (full stacktrace is available ​here):
django.db.utils.IntegrityError: duplicate key value violates unique constraint "idx_18141_auth_permission_content_type_id_01ab375a_uniq" DETAIL: Key (co.ntent_type_id, codename)=(12, add_agency) already exists.

It looks like the migration is trying to re-create already existing entries in the auth_permission table. At first I though it cloud because we recently renamed a model. But after digging and deleting the entries associated with the renamed model from our database in the auth_permission table, the problem still occurs with other proxy models.

I tried to update directly from 2.0.13 and 2.1.8. The issues appeared each time. I also deleted my venv and recreated it without an effect.

I searched for a ticket about this on the bug tracker but found nothing. I also posted this on ​django-users and was asked to report this here.

[Tim Graham]

Please provide a sample project or enough details to reproduce the issue.

[Kia Hosseini]

Same problem for me.
If a Permission exists already with the new content_type and permission name, IntegrityError is raised since it violates the unique_key constraint on permission model i.e. content_type_id_code_name

[Sébastiaan Versteeg]

To get into the situation where you already have permissions with the content type you should be able to do the following:

• Start on Django <2.2
• Create a model called 'TestModel'
• Migrate
• Delete the model called 'TestModel'
• Add a new proxy model called 'TestModel'
• Migrate
• Update to Django >=2.2
• Migrate

We think this is what happened in our case where we found this issue (​https://sentry.thalia.nu/share/issue/68be0f8c32764dec97855b3cbb3d8b55/).
We have a proxy model with the same name that a previous non-proxy model once had. This changed during a refactor and the permissions + content type for the original model still exist.
Our solution will probably be removing the existing permissions from the table, but that's really only a workaround.

[Mariusz Felisiak]

Reproduced with steps from comment. It's probably regression in 181fb60159e54d442d3610f4afba6f066a6dac05.