Opened 17 months ago

Closed 17 months ago

Last modified 17 months ago

#34762 closed Bug (duplicate)

Duplicate Permissions Created on Model Rename

Reported by: Dipak Pawar Owned by: nobody
Component: contrib.auth Version: 4.2
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

Description

Dear Django Community,

I hope this message finds you well. I am writing to share an issue that I encountered in my Django project while renaming a model. Initially, I had a model named "Group," but later, I decided to rename it to "CollegeGroup" to better reflect its purpose in the project. However, after renaming the model, I noticed an unexpected behavior in the permissions system.

Upon renaming the model, duplicate permissions are being created for the renamed model. Consequently, two sets of permissions with identical functionalities exist—one set with codenames like "add_group," "change_group," "view_group," "delete_group," and another set with codenames like "add_collegegroup," "change_collegegroup," "view_collegegroup," "delete_collegegroup."

This situation has raised concerns as it can lead to confusion among developers and administrators, and potentially result in the misuse of permissions. We believe that the presence of duplicate permissions for the same functionality is undesirable and can be improved to ensure a more streamlined and intuitive experience.

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.
https://ibb.co/5RBB1nS
https://ibb.co/1dstwLw

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.

Change History (2)

comment:1 by Natalia Bidart, 17 months ago

Resolution: duplicate
Status: newclosed

Duplicate of #27489.

comment:2 by Tim Graham, 17 months ago

Component: Core (Other)contrib.auth
Type: UncategorizedBug
Note: See TracTickets for help on using tickets.
Back to Top