Opened 15 years ago
Last modified 3 years ago
#12382 new Bug
Deleting an inline can delete the whole inlined model instance recursively
Reported by: | Dirk Eschler | Owned by: | nobody |
---|---|---|---|
Component: | contrib.admin | Version: | 1.1 |
Severity: | Normal | Keywords: | admin inlines |
Cc: | eschler@…, bugs@…, Carsten Fuchs | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Pull Requests: | How to create a pull request | ||
Description ¶
A deleted inline can delete the whole inlined model (and all its related ForeignKeys) if the inlined model has a ForeignKey back to model it inlines. As this is best illustrated by an example, here's some code:
models.py:
class Telephone(models.Model): TELEPHONE_TYPES = ( ('WORK', 'Work'), ('HOME', 'Home'), ) telephone_type = models.CharField(max_length=16, choices=TELEPHONE_TYPES) number = models.CharField(max_length=100) contact = models.ForeignKey('Contact') # ... class Contact(models.Model): family_name = models.CharField(max_length=255, null=True, blank=True) given_name = models.CharField(max_length=255, null=True, blank=True) # ... preferred_telephone = models.ForeignKey(Telephone, related_name='preferred_telephone', null=True, blank=True)
admin.py:
from class TelephoneInline(admin.TabularInline): model = Telephone class TelephoneAdmin(admin.ModelAdmin): # ... class ContactAdmin(admin.ModelAdmin): # ... inlines = [ TelephoneInline, ]
Steps:
- Create a contact with a telephone number through the admin and save it
- Choose the new telephone number as preferred_telephone and save the contact
- Check the delete checkbox for the telephone number
- Save
Expected:
The telephone number is deleted.
Result:
The contact is deleted recursively! In addition a 404 is raised that the contact doesn't exist, which is true.
If the Contact model had more relations, like a ForeignKey relation to an Address model for instance, all the addresses of the contact would have been deleted, too.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Change History (11)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 15 years ago
Cc: | added |
---|
comment:3 by , 14 years ago
#7539 is now fixed; the deletion here, if undesired, can be resolved by setting the on_delete argument to the ForeignKey appropriately.
The 404 / UI issue here remains.
comment:4 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:5 by , 14 years ago
UI/UX: | set |
---|
comment:10 by , 9 years ago
Cc: | added |
---|
comment:11 by , 3 years ago
Cc: | added |
---|
The deletion itself is a case of working as designed. #7539 exists to address the control of delete cascading behavior.
This leaves the UI problem - if deleting an inline leads to deleting the base object, you shouldn't get a 404. We track the objects that are going to be deleted; that could be used as a basis for redirection (i.e., if self on list, redirect to the "model" page in the admin)