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.
[[Image(https://ibb.co/5RBB1nS)]]
[[Image(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.
--
Ticket URL: <https://code.djangoproject.com/ticket/34762>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* status: new => closed
* resolution: => duplicate
Comment:
Duplicate of #27489.
--
Ticket URL: <https://code.djangoproject.com/ticket/34762#comment:1>
* type: Uncategorized => Bug
* component: Core (Other) => contrib.auth
--
Ticket URL: <https://code.djangoproject.com/ticket/34762#comment:2>