id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
21771	ModelAdmin's log_deletion method behaves incorrectly compared to other log methods	Keryn Knight <django@…>	nobody	"The current implementation of [https://github.com/django/django/blob/8f04f53dd847896f49a9bc367bb7269984ebdb6e/django/contrib/admin/options.py#L713 log_deletion] makes use of `self.model` to figure out the appropriate `content_type`, even though `object` is passed in. The `log_addition` and `log_change` methods correctly use the provided object to ascertain the type.
I can only assume that at some point obj wasn't intended/guaranteed to exist at the point `log_deletion` is called, but in both places it's used ([https://github.com/django/django/blob/8f04f53dd847896f49a9bc367bb7269984ebdb6e/django/contrib/admin/options.py#L1580 ModelAdmin.delete_view], [https://github.com/django/django/blob/17c66e6fe77bc5eb2bd9e6f8f032a105d3cac3d7/django/contrib/admin/actions.py#L48, actions.delete_selected]) there is already a requirement (or at least an assumption) that the object exists.

I consider this to be a bug, because it means that the following use case doesn't work, which is how I came across it:
{{{
class MyModelAdmin(ModelAdmin):
    def log_deletion(self, request, object, object_repr):
        super(MyModelAdmin, self).log_deletion(request, object, object_repr)
        super(MyModelAdmin, self).log_deletion(request, object.content_object, object_repr)
}}}
where `object.content_object` is a GFK back to the ""owner"" of the object.
Instead of getting two deletion messages, to the instance and the GFK/parent, you end up with two for the instance, because the content_type of the GFK/parent is never used.

The equivalent code for the `log_addition` and `log_change` methods appears to work."	Bug	closed	contrib.admin	dev	Normal	fixed			Accepted	0	0	0	0	0	0