Fixed #10919 -- Added ModelAdmin option to truncate delete confirmation object list. by rodbv · Pull Request #20903 · django/django

rodbv · 2026-03-14T01:15:52Z

Trac ticket number

Branch description

The original ticket proposed adding an option to limit or hide the list of related objects shown on the delete confirmation page. This list can become very long, especially for complex object graphs, because related items are rendered recursively. As a result, the confirmation button is pushed far down the page.

This PR implements a suggestion by @terminator14 (comment 13) to truncate the list at a given number, which is configurable, and complement the list with …and N more.

The setting is called delete_confirmation_max_display and its default value is None, which means it's an opt-in setting.

class PostAdmin(admin.ModelAdmin):
    delete_confirmation_max_display = 100
    # .... more settings

It renders like this

Shows how a list is complemented with an li having the text ... and 200 more

Dark mode - note that truncation is also applied to nested items

This still gives the user a good sense of the impact of the deletion, but keeps the page size and memory usage within reasonable limits.

AI Assistance Disclosure (REQUIRED)

No AI tools were used in preparing this PR.
If AI tools were used, I have disclosed which ones, and fully reviewed and verified their output.

Used GitHub Copilot to request an initial review, considering the practices found on the codebase, and also to generate HTML for test cases. I fully reviewed and verified all output before submitting this PR. The solution/algorithm is mine.

Checklist

This PR follows the contribution guidelines.
This PR does not disclose a security vulnerability (see vulnerability reporting).
This PR targets the main branch.
The commit message is written in past tense, mentions the ticket number, and ends with a period (see guidelines).
I have not requested, and will not request, an automated AI review for this PR.
I have checked the "Has patch" ticket flag in the Trac system.
I have added or updated relevant tests.
I have added or updated relevant docs, including release notes if applicable.
I have attached screenshots in both light and dark modes for any UI changes.

github-actions

Hello! Thank you for your contribution 💪

As it's your first contribution be sure to check out the patch review checklist.

If you're fixing a ticket from Trac make sure to set the "Has patch" flag and include a link to this PR in the ticket!

If you have any design or process questions then you can ask in the Django forum.

Welcome aboard ⛵️!

django/contrib/admin/templates/admin/delete_confirmation.html

naranjo-it · 2026-03-15T14:12:16Z

nicely done @rodbv 👏 . I like your solution, but I was wondering if instead of having the plain text "...and N more" you could make it into a link that will show the full results.
Or another idea would be to introduce pagination to call and navigate the results, but not sure how easy would be to integrate pagination into this view.

All optional of course, in my opinion as it is already adds value for this use case :)

rodbv · 2026-03-15T14:14:59Z

nicely done @rodbv 👏 . I like your solution, but I was wondering if instead of having the plain text "...and N more" you could make it into a link that will show the full results. Or another idea would be to introduce pagination to call and navigate the results, but not sure how easy would be to integrate pagination into this view.

All optional of course, in my opinion as it is already adds value for this use case :)

Thanks @naranjo-it! I will check both possibilities, I guess that making the "...and N more" text a link that reloads the page with truncation disabled is pretty straightforward and it would ensure users don't lose the ability to check any specific objects if they want to.

rodbv · 2026-03-17T13:11:14Z

nicely done @rodbv 👏 . I like your solution, but I was wondering if instead of having the plain text "...and N more" you could make it into a link that will show the full results. Or another idea would be to introduce pagination to call and navigate the results, but not sure how easy would be to integrate pagination into this view.
All optional of course, in my opinion as it is already adds value for this use case :)

Thanks @naranjo-it! I will check both possibilities, I guess that making the "...and N more" text a link that reloads the page with truncation disabled is pretty straightforward and it would ensure users don't lose the ability to check any specific objects if they want to.

After some checks, it's not that straighforward because one of the ways to get to the confirmation page is via POST, when a user selects one or more objects in the list view and picks the "delete" action.

So I will leave the PR as it is by now, to avoid adding too much complexity, and see what else is requested.

jacobtylerwalls

Thanks for the start here @rodbv, any progress we can make on this problem is going to be very welcomed by folks, I think!

So, my first thought is: I'm assuming an important part of the performance problem is fetching millions of rows from the db, not necessarily just rendering the million <li> rows. Did you look into an approach that would slice the queryset or otherwise limit the collected objects up front?

django/contrib/admin/templates/admin/delete_confirmation.html

django/template/defaultfilters.py

docs/ref/contrib/admin/index.txt

django/contrib/admin/checks.py

django/template/defaultfilters.py

jacobtylerwalls · 2026-03-17T20:07:40Z

django/template/defaultfilters.py

    def list_formatter(item_list, tabs=1):
        indent = "\t" * tabs
        output = []
+        truncated_count = 0


This counter gets reset on each recursion, so I'm getting n * m related objects for a limit of n and m related models.

Yes, that's by design, from this perspective: Suppose we have a blog system and we're applying delete_confirmation_max_objects on BlogAdmin, with value 30. From the user's perspective, it means "it want to see at most 30 posts on the confirmation page, and you can truncate the rest". So if there are more than 30 posts, they will consistently see 30 items and then "...and N more".

If we adopt a global counter, and the first post happens to have 100 comments, they would see only 1 post, 29 comments of the first post. If the order of posts change, they may see different numbers of posts.

Having said that I'm not totally against a global counter, if you prefer, I went for the most conservative approach.

@jacobtylerwalls Now that you showed me the case for mixed types on the same level, I am reconsidering this approach, as it may be hiding some types anyway. Maybe make the counter global and have at the end an outdented message like "N objects not displayed" could be better. What do you think?

I think this is a great time to go to the forum.

Since new ModelAdmin attributes are only a couple steps lower on the ladder of Debatable Ideas than new settings (😄), and since this ticket was accepted ~17 years ago without a clear statement of "yes, let's add a ModelAdmin attribute", I think it would be good to loop in other voices besides mine.

I would succinctly state:

why you are focusing on the front-end truncation solution only (I took it to be that even with a backend solution we'd still want to tune the front-end display?)

the issue with mixed types and how we have to choose between a global counter versus n^max_depth, showing an example of the two possible outputs

Finally, we also need to decide what approach harmonizes best with #20945, which implements a backend limit for a very similar use case.

Done. I can only post 1 embedded image and 2 links on my post there, as it's my first topic (got an error message when I submitted). So I will upload a preview of the global solution here and link :P

Thanks! (I think the forum post link to this 404's for me, maybe take another look?)

Weird 🤔 It's in Django Internals, with title Design feedback: Truncating the related objects list in Admin delete confirmation (Ticket #10919)

Oh, I just meant the link to the above image at "[you can see an example here]"

django/template/defaultfilters.py

rodbv · 2026-03-18T23:45:54Z

Thanks for the start here @rodbv, any progress we can make on this problem is going to be very welcomed by folks, I think!

So, my first thought is: I'm assuming an important part of the performance problem is fetching millions of rows from the db, not necessarily just rendering the million <li> rows. Did you look into an approach that would slice the queryset or otherwise limit the collected objects up front?

get_deleted_objects needs to traverse the full deletion graph to get all the counters it needs for the objects to be directly deleted and also its nested objects, splitting counters by protected, not permitted etc. I couldn't think of a feasible way to optimize this, unless I go for a big rewrite of get_deleted_objects.

My focus on this PR is on the frontend: reduce the amount of data sent to the browser, and the annoyance of scrolling a long way down to reach the "I'm sure" button.

For millions of items it will be a problem indeed, but hopefully for most cases (thousands of items) the db performance is not too bad.

jacobtylerwalls

This looks great! Just a handful of very minor questions for you about wording and such.

docs/ref/contrib/admin/index.txt

django/contrib/admin/templatetags/admin_filters.py

django/contrib/admin/actions.py

tests/admin_views/test_templatetags.py

docs/ref/contrib/admin/index.txt

rodbv · 2026-03-21T13:20:17Z

tests/template_tests/filter_tests/test_unordered_list.py

            "<li>D</li>",
        )

+    def test_non_iterable_list_subclass(self):


Adds test coverage for type error check on _walk_items.

…_unordered_list filter.

…dmin. The new ModelAdmin.delete_confirmation_max_display attribute allows limiting the number of related objects shown on the delete confirmation page. When the limit is reached, a "…and N more." message is shown. The feature relies on a new truncated_unordered_list template filter added to django.contrib.admin.templatetags.admin_filters. Thanks Jacob Tyler Walls for the review, Tobias McNulty for the report, and terminator14 for the solution suggested.

tests/admin_views/test_actions.py

github-actions · 2026-03-24T21:25:03Z

Uncovered lines in changed files

-------------
django/contrib/admin/checks.py (100%)
django/contrib/admin/options.py (100%)
django/contrib/admin/templatetags/admin_filters.py (100%)
django/template/defaultfilters.py (100%)
-------------
Total:   58 lines
Missing: 0 lines
Coverage: 100%
-------------

Note: Missing lines are warnings only. Some database-specific lines may not be measured. More information

github-actions bot added the no ticket Based on PR title, no linked Trac ticket label Mar 14, 2026

github-actions bot reviewed Mar 14, 2026

View reviewed changes

rodbv force-pushed the ticket_10919 branch 2 times, most recently from f69a687 to 3a4e285 Compare March 14, 2026 09:45

rodbv changed the title ~~Ticket 10919~~ Fixed #10919 Mar 14, 2026

github-actions bot removed the no ticket Based on PR title, no linked Trac ticket label Mar 14, 2026

rodbv changed the title ~~Fixed #10919~~ Fixed #10919 -- Truncate list of deleted objects on delete confirmation page Mar 14, 2026

rodbv force-pushed the ticket_10919 branch from c7b0380 to 5f32293 Compare March 14, 2026 14:05

rodbv commented Mar 14, 2026

View reviewed changes

django/contrib/admin/templates/admin/delete_confirmation.html Outdated Show resolved Hide resolved

jacobtylerwalls added the Djangonauts 🚀 label Mar 14, 2026

rodbv force-pushed the ticket_10919 branch 5 times, most recently from 385d74a to c670447 Compare March 14, 2026 16:29

rodbv changed the title ~~Fixed #10919 -- Truncate list of deleted objects on delete confirmation page~~ Fixed #10919 -- Made delete confirmation object list truncation configurable. Mar 14, 2026

rodbv changed the title ~~Fixed #10919 -- Made delete confirmation object list truncation configurable.~~ Fixed #10919 -- Added ModelAdmin option to truncate delete confirmation object list. Mar 14, 2026

rodbv marked this pull request as ready for review March 14, 2026 16:33

rodbv force-pushed the ticket_10919 branch from 0fe051e to af16e73 Compare March 14, 2026 16:50

jacobtylerwalls added the coverage Generate a comment with a coverage diff label Mar 16, 2026

rodbv force-pushed the ticket_10919 branch from eb42d09 to 8637d70 Compare March 17, 2026 13:31

django deleted a comment from github-actions bot Mar 17, 2026

jacobtylerwalls reviewed Mar 17, 2026

View reviewed changes

django deleted a comment from github-actions bot Mar 17, 2026

rodbv commented Mar 18, 2026

View reviewed changes

django/template/defaultfilters.py Show resolved Hide resolved

jacobtylerwalls approved these changes Mar 20, 2026

View reviewed changes

jacobtylerwalls reviewed Mar 20, 2026

View reviewed changes

docs/ref/contrib/admin/index.txt Outdated Show resolved Hide resolved

rodbv commented Mar 21, 2026

View reviewed changes

rodbv force-pushed the ticket_10919 branch 4 times, most recently from 81793f7 to 41aa1e8 Compare March 22, 2026 12:58

rodbv added 2 commits March 22, 2026 10:06

Refactored walk_items as module-level _walk_items and added truncated…

216460e

…_unordered_list filter.

rodbv force-pushed the ticket_10919 branch from 41aa1e8 to 9fce012 Compare March 22, 2026 13:08

jacobtylerwalls reviewed Mar 24, 2026

View reviewed changes

tests/admin_views/test_actions.py Outdated Show resolved Hide resolved

Fixed test names after attribute rename.

299274c

Uh oh!

Conversation

rodbv commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Trac ticket number

Branch description

AI Assistance Disclosure (REQUIRED)

Checklist

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

naranjo-it commented Mar 15, 2026

Uh oh!

rodbv commented Mar 15, 2026

Uh oh!

rodbv commented Mar 17, 2026

Uh oh!

jacobtylerwalls left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jacobtylerwalls Mar 17, 2026

Choose a reason for hiding this comment

Uh oh!

rodbv Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rodbv Mar 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacobtylerwalls Mar 24, 2026

Choose a reason for hiding this comment

Uh oh!

rodbv Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacobtylerwalls Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

rodbv Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

jacobtylerwalls Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rodbv commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacobtylerwalls left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rodbv Mar 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions bot commented Mar 24, 2026

Uncovered lines in changed files

Uh oh!

Reviewers

Assignees

Labels

rodbv commented Mar 14, 2026 •

edited

Loading

rodbv Mar 17, 2026 •

edited

Loading

rodbv Mar 21, 2026 •

edited

Loading

rodbv Mar 25, 2026 •

edited

Loading

rodbv commented Mar 18, 2026 •

edited

Loading