Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1787 closed defect (fixed)

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)

comment:1 Changed 12 years ago by eugene@…

Summary: Clarification of auth_permission.content_type_id is neededRegeneration of permissions after magic-removal switch

Super users are affected too: they cannot add/delete/change users and groups after the migration.

The simplest way to make everything working again:

  • Delete a content of
    • auth_group_permissions
    • auth_permissions
    • auth_user_user_permissions
    • django_content_type
  • Run 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 of auth_permission table is not used anymore. Why keep deadwood around? It should be dropped during the migration procedure. Something like this works for MySQL:

ALTER TABLE `auth_permission` DROP COLUMN `package`;

comment:2 Changed 12 years ago by Adrian Holovaty

Resolution: fixed
Status: newclosed

Fixed, I think.

comment:3 Changed 12 years ago by bmurdock@…

Resolution: fixed
Status: closedreopened

I tried the suggested delete-everything suggestion and ran into issues:

=> delete from django_content_type;
ERROR:  update or delete on "django_content_type" violates foreign key constraint "django_admin_log_content_type_id_fkey" on "django_admin_log"
DETAIL:  Key (id)=(1) is still referenced from table "django_admin_log".

I think there needs to be some instructions on the right alterations to columns in these tables to do the magic-removal update. It seems like maybe you just need to change all the models listed in django_content_type from plural to singular, but I haven't been able to verify that yet.

comment:4 Changed 12 years ago by Here

Type: enhancementdefect

comment:5 Changed 12 years ago by Adrian Holovaty

Resolution: fixed
Status: reopenedclosed

Fixed in revision 156 of RemovingTheMagic.

Note: See TracTickets for help on using tickets.
Back to Top