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_permissions
auth_permissions
auth_user_user_permissions
django_content_type
django-admin.py
/manage.py
syncdb
It 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
syncdb
is not documented. I hope it'll be added.Apparently
package
column ofauth_permission
table is not used anymore. Why keep deadwood around? It should be dropped during the migration procedure. Something like this works for MySQL: