Admin's Recent Actions will link to a 404 when an object has been deleted.

[anonymous]

A page not found (404) is begin show when clicking on an add or edit action of a (later) deleted object in Recent Actions.

For the delete action, there is already no link on the object. But the older add and edit actions in the Recent Actions list have at this time no valid URL beacause the object is already deleted.

Because this list is in chronological order, one could disable the links on the add and edit actions in Recent Actions that have taken place earlier that the delete. With again allowing a link on a later than the delete created new object with another add actin.

This change would make de admin page more stable since this will also be used with less technical personel and will ensure that the Recent Actions has only valid (non 404) URLs.

[Simon G. <dev@…>]

confirmed on latest svn.

[ionut bizau]

Added a new field (object_exists) to LogEntry, which becomes False after the object that that entry is referring to is deleted. I think this approach is better than just looking for the object by id, both for performance and for the situation where an object with the same id is added later. This field is then checked in the template.

[ionut bizau]

Add myself to AUTHORS.

[Karen Tracey <kmtracey@…>]

Replying to:

Added a new field (object_exists) to LogEntry?, which becomes False after the object that that entry is referring to is deleted. I think this approach is better than just >looking for the object by id, both for performance and for the situation where an object with the same id is added later. This field is then checked in the template.

Isn't this a major backwards-incompatible change? My existing DB's django_admin_log table doesn't have this new field. I don't expect when I pull a new svn checkout that I have to resync my db tables to accommodate changes like this....

[ionut bizau]

Replying to Karen Tracey <kmtracey@gmail.com>:

Isn't this a major backwards-incompatible change? My existing DB's django_admin_log table doesn't have this new field. I don't expect when I pull a new svn checkout that I have to resync my db tables to accommodate changes like this....

Being before 1.0 I guess we can break compatibility, but I am not sure to what degree. Let's wait for input from a core member.

[Karen Tracey]

I don't believe this problem warrants the backwards-incompatible change of modifying the admin table schema. We're also past 1.0 now so if this is to be fixed in the 1.x line a backwards-compatible way of doing it needs to be developed.

[Dennis Kaarsemaker]

Backwards compatible patch

[Dennis Kaarsemaker]

Here is a first stab at a backwards compatible patch. It's rather heavy as it requires at least one SQL query per displayed log entry so I'm not sure the approach is the best. It also needs tests for the added function.

[DmitriyShini]

I used this patch for Django v1.3 alha. Now it's worked, but it removes a functional.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[lpiatek]

Pull request/patch for 1.6 is here ​https://github.com/django/django/pull/1144

[Wiktor]

Pull request looks good, assertions provided too.

[Marc Tamlyn]

Hmm, I don't like this approach. An alternative could be to insert an additional redirect view which will check whether the object exists, and if not redirect to the root of the admin with a redirect.

Another wider reaching alternative would be to generally improve 404 handling in the admin so it gives nicer messages and redirects.

[Karen Tracey]

Tried to address Marc's concerns in new PR ​https://github.com/django/django/pull/7495

[Carl Meyer]

Is this really even a bug? Seems to me that if this link is supposed to go to the admin page for the object, and the object no longer exists, a 404 is a pretty reasonable response. Do we just need a nicer default 404 page in the admin?

[Karen Tracey]

I do believe it is confusing for general users for the admin to be offering links to pages which then 404. It was accepted 10 years ago and seemed reasonable to me. Not all admin users are sophisticated users who immediately jump from 404 to "oh that thing must be gone", rather they get the impression from the "broken links" that the admin is broken/unreliable somehow. I likely would have first gone for the "just don't make it a link in recent actions" approach but given that had been rejected already I tried an alternative way. Running DEBUG mode the reason for the 404 is clear since the Http404 messages are visible then to the user, but those are not visible when DEBUG is off, so I though making them a message the user would see would be a small improvement. I'm not particularly willing to tackle improving the 404 page of admin in general.

[Tim Graham <timograham@…>]

In 27267afc:

Fixed #2856 -- Replaced some 404s with messages in admin.

Instead of a 404, return a redirect to admin index page with a message
indicating that the requested object does not exist. This avoids the
admin returning 404 from "Recent Actions" links for deleted objects.

[Tim Graham <timograham@…>]

In 8ea541e:

Refs #2856 -- Removed redundant escaping in admin's "Perhaps it was deleted?" message.