Duplicate Permissions Created on Model Rename

Using Django The Admin
1

Bug Report: Duplicate Permissions Created on Model Rename

Description: After renaming the model from “Group” to “CollegeGroup” in my Django project, duplicate permissions are being created for the renamed model. This results in two sets of permissions with the same functionality, one set with codenames like “add_group”, “change_group”, “view_group”, “delete_group” and the other set with codenames like “add_collegegroup”, “change_collegegroup”, “view_collegegroup”, “delete_collegegroup”. This can lead to confusion and potential misuse of permissions.

from django.contrib.auth.models import Group as DJGroup

class Group(DJGroup):
    description = models.TextField(blank=True, null=True, max_length=200)
    college = models.ForeignKey("colleges.college", on_delete=models.CASCADE)

Rename the Model as below

class CollegeGroup(DJGroup):
    description = models.TextField(blank=True, null=True, max_length=200)
    college = models.ForeignKey("colleges.college", on_delete=models.CASCADE)

    class Meta:
        db_table = "college_group"

Steps to Reproduce:

  1. Create a Django project with an app containing a model named “Group.”
  2. Run migrations and create permissions for the model. Observe the permissions created for “Group.”
  3. Rename the model from “Group” to “CollegeGroup” in the app’s models.py.
  4. Create a new migration after renaming the model.
  5. Run migrations again and observe the permissions created for “CollegeGroup.”

Expected Behavior: After renaming the model from “Group” to “CollegeGroup,” the existing permissions for “Group” should be updated to apply to “CollegeGroup.” No new permissions with codenames like “add_collegegroup,” “change_collegegroup,” “view_collegegroup,” and “delete_collegegroup” should be created. The permissions for “CollegeGroup” should have the same functionality as the previous permissions for “Group.”

Actual Behavior: Upon renaming the model, Django creates new permissions with codenames like “add_collegegroup,” “change_collegegroup,” “view_collegegroup,” and “delete_collegegroup” alongside the existing permissions for “Group” (e.g., “add_group,” “change_group,” etc.). This results in duplicate permissions for the same functionality, which can cause confusion and potential misuse of permissions.

Environment:

  • Django version: 4.2.3
  • Python version: 3.10.6
  • Database: SQLite
  • Operating System: Windows

Screenshots:
I have attached the screenshots that illustrate the issue.
image 1
image 2

Impact: This bug can lead to confusion and potential security risks if users apply the wrong permissions using duplicate codenames. It affects the integrity of the permissions system and can result in unintended access controls.

Proposed Solution: Django should update the existing permissions when renaming a model, ensuring that the permissions continue to apply to the renamed model. No new permissions should be created unless explicitly specified.

Possible Workaround: As a temporary workaround, users can manually remove the duplicate permissions created after renaming the model. However, this is not a scalable solution and may result in data loss or misconfiguration.

2

This does seem like odd behavior. Renaming a model keeps the same ContentType id, so there doesn’t appear to me to be an issue with keeping the same permission objects.

I suggest you submit this as an actual ticket at https://code.djangoproject.com/newticket. (If you don’t already have an account on the site, see https://code.djangoproject.com/)

3

Hello @KenWhitesell

Thanks for your response. I appreciate your insight into the issue. However, I have noticed that after renaming the model, multiple permissions are displayed in the Admin Panel when I try to assign permissions to a particular user or group for the single model (Group and CollegeGroup).

I understand that the ContentType id remains the same after renaming the model, but the issue seems to be with how Django handles permissions in this scenario. The duplicated permissions can lead to confusion and potential misuse if not addressed properly.

I will definitely submit this as a ticket on the Django website (https://code.djangoproject.com/newticket) to bring attention to the behavior I observed. Thank you for suggesting that.