Design feedback: Truncating the related objects list in Admin delete confirmation (Ticket #10919)

Django Internals
1

Hello everyone,

I’m working on PR #20903, which addresses a long-standing ticket (#10919) regarding the delete confirmation page in contrib.admin.

Currently, when deleting an object with many children, the recursive list of related objects can become massive (see example on ticket). This pushes the “Yes, I’m sure” button far out of view and can lead to extremely large HTML payloads that degrade the browser experience and accessibility.

The proposed solution in the PR adds a new attributeModelAdmin.delete_confirmation_max_display, to cap the visual list, i.e show the first 100 items and then “…and N more”. The default value is None, which makes this attribute/feature opt-in.

This is how the change looks like if we set the value to 2 (probably users would pick a higher number, but I just want to keep the screenshot short)

image
image1440×1100 79.4 KB

This is a frontend-only optimization, we’re not limiting the database query. One of the main reasons is that we need to traverse the whole recursive tree to collect the counters of all nested objects anyway, to show the summary on the top of the page, it’s the same set of queries.

One of the decisions we’ve been going back and forth on the PR is whether we should cap the items per nesting level or globally, and I wonder if we can get to a consensus here.

Truncating per nesting level is like the screenshot above; for example, if I set a limit of 10, I would expect to see 10 children at most, and then 10 grandchildren for each, and so on. The rationale is that I’d rather see 10 posts than 1 post and 9 comments, to have a better sense of what’s being deleted, it maximizes visibility of the items affected.

One downside is that if we have mixed types on the same level like

Foo:
Bar:
Baz:
…and 2 more

..it may look like there are 2 more “Baz” which is not necessarily true, it could be anything.

OTOH If we truncate globally, we could have a message like “…and N more objects” only once, at the end of the list, and have a more predictable page size, like the screenshot linked next. In this case the limit was set to 10, so it shows 1 blog, 1 post and 8 comments (total 10) - you can see an example here.

Do you have any preferences? see a better alternative?

Please let me know if anything is unclear. Thanks @jacobtylerwalls for the great suggestions and guidance on this PR, it’s my first :wink: Cheers!

2 Likes
2

Thanks for bring this up robv, and looking into solutions.

This becomes an issue for large projects that have scaled. At which point there should hopefully be some team that is able to work on a solution for their codebase. For projects yet to scale, the UI concern seems minor to me and they won’t hit the slow page load situation.

I like the make “the easy things easy and the complex things possible” approach. If this page is a problem it is already possible to overwrite the get_deleted_objects function and have your model with lots of data only provide a confirmation page, you are even free to add an additional view that you hook up to that page to do the collection on an as needs basis, in case you are worried about what gets deleted, at that stage you know your project you can even limit the search to the data you’d be worried about deleting or the objects that could have delete protection/restriction.

So I’d vote we don’t really need this extra complication to the admin, and I’d vote we close the ticket with a note to that effect.

1 Like
3

Wouldn’t it be better to enclose it in a scrollable view with a max height? That way if anyone wants to check it in full they can do it. The downside is that sometimes it takes a very long time to load all the report.

Personally I wouldn’t mind one solution or other, I just wanted to point to another way of doing it.

4

Thank you for working on the ticket @rodbv
I like the way the solution looks!

The original ticket is concerned about the memory usage of such a big page (#10919 (Add an option to disable display of related items on admin's delete confirmation page (to prevent large memory usage on complex objects)) – Django), therefore adding a scrollbar does not resolve the reported issue imo.
I am curious what is the accessibility concern is for having the “Yes, I’m sure” at the bottom of a large page that would require scrolling? If the accessibility team feels this makes the page unusable for folks using assistive technologies, then I would even be in favor of us implementing a delete_confirmation_max_display value by default.

I would vote for a global limit.

I agree that folks should feel empowered to overwrite pages as they see fit. For example, if I was customizing it, I would have a load more/paginated approach using a bit of htmx, but for Django core, that’s overkill.
I feel this problem has been felt by folks every now and again and setting 1 attribute to resolve this is probably welcome.

1 Like
Django Fellow Report - Sarah - 2026
5

If we were implementing this page today, I don’t think we’d merge it without some sort of limit mechanism, so adding one attribute feels fine.

I also vote for the global limit (it’s just simpler).

6

Thanks a lot for the feedback everyone, I will give the global limit a shot.