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 ,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