Regeneration of permissions after magic-removal switch
| Reported by: |
eugene@… |
Owned by: |
Jacob |
|
Component:
|
Documentation
|
Version:
|
|
|
Severity:
|
normal
|
Keywords:
|
|
|
Cc:
|
|
Triage Stage:
|
Unreviewed
|
|
Has patch:
|
no
|
Needs documentation:
|
no
|
|
Needs tests:
|
no
|
Patch needs improvement:
|
no
|
|
Easy pickings:
|
no
|
UI/UX:
|
no
|
RemovingTheMagic describes how to add content_type_id integer field to auth_permission table. This new field is going to be initialized with 0. It breaks permissions for regular users (super users are not affected). Clearly this field should be properly initialized with IDs of proper django_content_type records. It would be nice, if RemovingTheMagic says so explicitly, or explains how to set them (re-installing apps?).
Change History
(5)
| Summary: |
Clarification of auth_permission.content_type_id is needed → Regeneration of permissions after magic-removal switch
|
| Resolution: |
→ fixed
|
| Status: |
new → closed
|
| Resolution: |
fixed
|
| Status: |
closed → reopened
|
| Type: |
enhancement → defect
|
| Resolution: |
→ fixed
|
| Status: |
reopened → closed
|
Super users are affected too: they cannot add/delete/change users and groups after the migration.
The simplest way to make everything working again:
auth_group_permissionsauth_permissionsauth_user_user_permissionsdjango_content_typedjango-admin.py/manage.pysyncdbIt repopulates the content of said tables properly. But an administrator has to reassign group and user permissions again in Admin. Obviously it can be a problem, if you have hundreds of users with arcane permissions.
It looks like
syncdbis not documented. I hope it'll be added.Apparently
packagecolumn ofauth_permissiontable is not used anymore. Why keep deadwood around? It should be dropped during the migration procedure. Something like this works for MySQL: