Code

Opened 8 years ago

Closed 8 years ago

Last modified 8 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: UI/UX:

Description

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?).

Attachments (0)

Change History (5)

comment:1 Changed 8 years ago by eugene@…

  • Summary changed from Clarification of auth_permission.content_type_id is needed to Regeneration 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 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 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 8 years ago by adrian

  • Resolution set to fixed
  • Status changed from new to closed

Fixed, I think.

comment:3 Changed 8 years ago by bmurdock@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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 8 years ago by Here

  • Type changed from enhancement to defect

comment:5 Changed 8 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

Fixed in revision 156 of RemovingTheMagic.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.