Opened 15 years ago
Last modified 12 years ago
#13369 new New feature
Should be easier to add a MultipleChoice for reverse relationships on ModelAdmins
Reported by: | Rowan Nairn | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.2 |
Severity: | Normal | Keywords: | |
Cc: | cainmatt@…, Jason Novinger | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
A question about this came up here and for me separately. Models which are referred to by a ForeignKey or ManyToManyField don't have a corresponding field in their admin Form. Especially in the ManyToManyField, where it is rather arbitrary as to which model has the ManyToManyField and which has the reverse relationship, it seems like it should be easier (if not the default) to have a ModelMultipleChoiceField for the reverse relationship as well as the forward one.
Change History (6)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
Cc: | added |
---|---|
Version: | 1.1 → 1.2 |
Solution for ManyToManyField
It is possible to get the right behavior by adding a ManyToManyField to both models. Then the field will be in both models and appear in the Admin tool by default. Example:
class Group(Model): members = ManyToManyField('Member', related_name='+') class Member(Model): groups = ManyToManyField(Group, through=Group.members.through, related_name='+')
Note:
- Using through=Group.members.through prevents manage.py sqlall listing the join table twice. It may also prevent duplication in ORM internals
- related_name='+' prevents models instances from having the group_set / member_set reverse lookup fields
- This is a small violation of DRY; it might be nice to have an option on ManyToManyField() to make the reverse relation a true many to many field instead of a reverse many to many field
- You can still use all the other ManyToManyField() parameters such as db_table, blank, etc
comment:3 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:6 by , 12 years ago
Cc: | added |
---|
This idea has been proposed previously and rejected, but I think it might be appropriate to revisit that decision. I can't find a previous ticket definition; it's possible it never got lodged, and was just rejected during feature development.
By way of implementation: we can't turn this on by default because of backwards compatibility -- existing forms shouldn't suddenly acquire a new m2m field that didn't previously exist -- but I can't see any reason that it shouldn't be legal in a 'fields' definition.