Opened 7 years ago
Closed 7 years ago
#28931 closed Cleanup/optimization (wontfix)
Non-conflicting `related_name` and `related_query_name` for `groups` and `user_permissions` columns in `PermissionsMixin`
| Reported by: | Saiteja Parsi | Owned by: | Saiteja Parsi |
|---|---|---|---|
| Component: | contrib.auth | Version: | 2.0 |
| Severity: | Normal | Keywords: | related_name, related_query_name, Abstract base classes, Model inheritance |
| Cc: | saiteja.parsi@… | Triage Stage: | Unreviewed |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
AbstractUser extends PermissionsMixin to add the fields and methods necessary to support the Groups and Permission. PermissionsMixin defines groups and user_permissions columns with many to many fields, both of which has a constant value for related_name and related_query_name' keys'. As AbstractUser inherit these fields, there is a high chance that these values raise conflicts when there are multiple classes inheriting from this abstract class, AbstractUser. So I suggest that instead of constant values for related_name and related_query_name' in PermissionsMixin', they should be dynamic values as described here.
Change History (3)
comment:1 by , 7 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 7 years ago
| Summary: | Non-conflicting `related_name` and `related_query_name` for `groups` column and `user_permissions` in `PermissionsMixin` → Non-conflicting `related_name` and `related_query_name` for `groups` and `user_permissions` columns in `PermissionsMixin` |
|---|
comment:3 by , 7 years ago
| Component: | Database layer (models, ORM) → contrib.auth |
|---|---|
| Resolution: | → wontfix |
| Status: | assigned → closed |
Note:
See TracTickets
for help on using tickets.
Closing as per Simon's comments from the PR, "I'm afraid this is going to break backward compatibility for every subclasses of PermissionsMixin, default User model included. From the top of my head I can't think of any solution that doesn't involve deprecation shims and migrations which all seems like a lot of work. ... this is going to require a non-negligible amount of work for something that can be worked around by using the _meta API for the rare cases when this is an issue."