Opened 8 years ago

Last modified 4 years ago

#26756 new Bug

Changing of model's verbose_name does not change the names of the model's permissions

Reported by: Dmitry Burakov Owned by:
Component: contrib.auth Version: dev
Severity: Normal Keywords: permissions verbose_name migrate
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by Dmitry Burakov)

I've found that changing the "verbose_name" of the Meta class of a model and than running migrations does not change the names of the model's permissions.

Steps to reproduce:

  1. Create a new model
class AwesomeModel(models.Model):
    class Meta:
        verbose_name = "My awesome model"
  1. Run "makemigrations" and than "migrate"
  2. Look at the generated permissions
select * from auth_permission;
 id  |                  name                  | content_type_id |             codename
-----+----------------------------------------+-----------------+----------------------------------
   1 | Can add my awesome model               |               2 | add_awesomemodel
   2 | Can change my awesome model            |               2 | change_awesomemodel
   3 | Can delete my awesome model            |               2 | delete_awesomemodel
  1. Change the "verbose_name" of the Meta class of the model
class AwesomeModel(models.Model):
    class Meta:
        verbose_name = "My really awesome model"
  1. Run "makemigrations" and than "migrate" again
  2. Look at the generated permissions agaun
select * from auth_permission;
 id  |                  name                  | content_type_id |             codename
-----+----------------------------------------+-----------------+----------------------------------
   1 | Can add my awesome model               |               2 | add_awesomemodel
   2 | Can change my awesome model            |               2 | change_awesomemodel
   3 | Can delete my awesome model            |               2 | delete_awesomemodel

As you can see the names of the model's permissions are not changed.
But! If now you drop the database and apply all the migrations to the empty database - the permissions will have correct names

select * from auth_permission;
 id  |                  name                  | content_type_id |             codename
-----+----------------------------------------+-----------------+----------------------------------
   1 | Can add my really awesome model        |               2 | add_awesomemodel
   2 | Can change my really awesome model     |               2 | change_awesomemodel
   3 | Can delete my really awesome model     |               2 | delete_awesomemodel

Change History (8)

comment:1 by Dmitry Burakov, 8 years ago

Description: modified (diff)

comment:2 by Simon Charette, 8 years ago

Triage Stage: UnreviewedAccepted
Version: 1.9master

comment:3 by Roman Hudec, 8 years ago

Owner: changed from nobody to Roman Hudec
Status: newassigned

comment:4 by Roman Hudec, 8 years ago

Has patch: set

I've tried to implement this in the management command, that handles creating non-existing permissions after migrating an app.

Here's a PR https://github.com/django/django/pull/6778

comment:5 by Tim Graham, 8 years ago

Patch needs improvement: set

I left a comment for improvement on the PR. Also tests are needed.

comment:6 by Roman Hudec, 8 years ago

I've tried the suggested injecting a migration operation approach, but somehow ended up with an unexpected exception saying Permission model cannot resolve 'content_type' into a field.

then i've tried optimizing my previous approach by only checking permissions for models that had verbose_name altered during the migration. that should be almost as effective as the suggested approach, and passed the test I've written, so I created a new PR ( https://github.com/django/django/pull/6837 ) for that approach.

comment:7 by Tim Graham, 8 years ago

Component: Migrationscontrib.auth

#27489 "Renaming a model doesn't rename the permission name and codename" is a related issue that would be useful to work on while in this area.

comment:8 by Mariusz Felisiak, 4 years ago

Owner: Roman Hudec removed
Status: assignednew
Note: See TracTickets for help on using tickets.
Back to Top