auth_permission rows get "duplicated" on ./deploy.sh

[IllyaMoskvin]

As of at least fadb34d, there is a major problem with the default_auth.json fixture. Almost all auth.permission objects contain outdated content_type references. Running python manage.py migrate after a fresh install causes "duplicate" references to content types in the auth_permission table. This also happens if you run ./deploy.sh at any time.

Specifically, permissions for content types that changed ids get duplicated. For instance, access_project in default_auth points to content_type: 13; therefore, the following row gets created in auth_permission:

40 | Access Project                     |              13 | access_project

However, after a fresh install, in the django_content_type table, project has an id of 16. Therefore, a second row gets created in auth_permission:

128 | Access Project                       |              16 | access_project

This occurs for all permissions for that content type:

37 | Can add project                      |              13 | add_project
38 | Can change project                   |              13 | change_project
39 | Can delete project                   |              13 | delete_project
40 | Access Project                       |              13 | access_project
...
125 | Can add project                      |              16 | add_project
126 | Can change project                   |              16 | change_project
127 | Can delete project                   |              16 | delete_project
128 | Access Project                       |              16 | access_project

Permissions for content types whose id matches that listed in default_auth.json do not get duplicated:

 1 | Can add permission                   |               1 | add_permission
 2 | Can change permission                |               1 | change_permission
 3 | Can delete permission                |               1 | delete_permission

This problem has been present for a long time; however, Django managed to work around it by referencing only the permissions for the new content type id. Now that we are using custom django-guardian permissions in the APIv2 branch, this issue is rearing its ugly head.

For anyone who stumbles on this page while troubleshooting your own projects, if you are using auth.permission fixtures with django-guardian, and if you get errors similar to the one below, check auth_permission for orphaned content_type references:

File "/var/www/roundware/source/roundware/rw/admin.py", line 99, in get_queryset
  return qset.filter(project__in=get_objects_for_user(request.user, 'rw.access_project'))
File "/usr/local/lib/python2.7/dist-packages/guardian/shortcuts.py", line 441, in get_objects_for_user
  permission__codename=codename)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 122, in manager_method
  return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 391, in get
  (self.model._meta.object_name, num)
MultipleObjectsReturned: get() returned more than one ContentType -- it returned 2!

I'm still trying to figure out what to do about this. My tentative recommendation is to do away with the auth.permission fixtures in default_auth.json and just let Django fill out the table as it sees fit. Furthermore, we should consider truncating the auth_permission table as part of the upgrade process to Django 1.9 (#283).

[IllyaMoskvin]

As an aside to passing troubleshooters, I now recommend running this query (PostgreSQL) to remove the "orphaned" entries:

DELETE FROM auth_permission WHERE id IN (SELECT id FROM auth_permission EXCEPT ((SELECT permission_id FROM auth_group_permissions) UNION (SELECT permission_id FROM auth_user_user_permissions)))

This will delete all entries from auth_permission that are not assigned to a user or a group. I figure that Django wouldn’t let permissions be assigned to non-existent content types, so it should be quite safe. The auth_permission table will be repopulated the next time you run python manage.py migrate. You will also have to remove any existing auth.permission fixtures you might have.

For our case, I included this command in the upgrade instructions and removed the fixtures.

This issue should be closed when PR #283 is merged.