In the Django admin, what does the built-in 'Delete selected' action do, and how do you remove it from one model or the whole site?

## What `delete_selected` is An **admin action** in `django.contrib.admin` is a function that runs over the rows a staff user ticks on a **change list** (the paginated table of records for one model). Django ships exactly one built-in action: **`delete_selected`**, defined in `django/contrib/admin/actions.py`. Every `AdminSite` registers it in its site-wide action registry when it is created, which is why every registered model shows **"Delete selected <verbose_name_plural>"** in the action dropdown without you writing anything. It is decorated like any custom action: - `permissions=["delete"]` — the action is only offered to users for whom `ModelAdmin.has_delete_permission(request)` returns `True`. - `description="Delete selected %(verbose_name_plural)s"` — the placeholder is filled from the model's `Meta.verbose_name_plural`. ## The two-step flow `delete_selected` is also the canonical example of an action with an **intermediate page**: 1. The user ticks rows, picks the action and clicks **Go**. The admin builds a queryset of the ticked primary keys and calls the action. 2. The action calls `ModelAdmin.get_deleted_objects()`, which runs Django's deletion **collector** and returns every object that would disappear by cascade, per-model counts, the permissions the user lacks, and any **protected** objects. 3. Because the POST has no `post` field yet, the action returns a `TemplateResponse` for `delete_selected_confirmation.html`. That page lists the whole cascade and carries hidden inputs: each selected primary key, `action=delete_selected` and `post=yes`. 4. On confirmation the same action runs again, sees `post`, calls `log_deletions()` (writing `LogEntry` history rows **before** the delete), then `delete_queryset(request, queryset)`, then `message_user()` with "Successfully deleted N …", and returns `None`, so the admin redirects back to the change list. If any collected object is protected by `on_delete=PROTECT` or `RESTRICT`, or belongs to a registered model the user may not delete, the page titles itself **"Cannot delete …"** and offers no confirm button. A hand-crafted confirming POST in that state still does not delete: protected objects skip the delete branch, and missing permissions raise `PermissionDenied`. ## Removing or restricting it | Scope | How | Effect | |---|---|---| | Whole site | `admin.site.disable_action("delete_selected")` | Gone from every change list on that site | | One model, back in after a global disable | `actions = ["delete_selected"]` on that `ModelAdmin` | The name still resolves through the site's registry | | One model, per request | Override `get_actions()` and pop `"delete_selected"` | E.g. only superusers keep it | | One model, all actions | `actions = None` | No dropdown and no checkbox column | | Via permissions | Deny `has_delete_permission()` | Also removes deletion from the change form | `disable_action()` only removes the action from the **enabled** set; the site keeps a second registry of every action ever added, which is why a `ModelAdmin` can name it again. ## What it does not do - It does **not** call each object's `Model.delete()`. The default `delete_queryset()` runs `queryset.delete()` for efficiency; what that skips is a QuerySet-API subject, and the admin-side fix is overriding `delete_queryset()`. - Its object-level check is limited to the collector pass: `has_delete_permission(request, obj)` is asked for every collected object of a registered model, the selected rows included, but which rows could be ticked at all is decided upstream by `get_queryset()`. - In Django 6.1 the new `delete_confirmation_max_display` option truncates long cascade lists on the confirmation page; the default `None` shows them all. ## Why interviewers ask it Juniors are expected to know the action exists, that it confirms first, and that it can be switched off. The follow-up — "why didn't my custom `delete()` run?" — separates people who have used the admin in production from those who have only registered models. ## Customising the confirmation page The page is an ordinary template, so it can be adapted without rewriting the action: - **`delete_selected_confirmation_template`** on a `ModelAdmin` names a template to use instead of the default. - Without it, the action looks up, in order, `admin/<app_label>/<model_name>/delete_selected_confirmation.html`, then `admin/<app_label>/delete_selected_confirmation.html`, then the built-in `admin/delete_selected_confirmation.html`, so a project can override one model or one app. - **`get_deleted_objects(objs, request)`** is a `ModelAdmin` hook; override it to change what the page lists or which permissions it demands. - **`delete_confirmation_max_display`** (Django 6.1) caps how many collected objects are listed before the rest is summarised, which matters when one customer row cascades into thousands of order lines. ## A quick way to check your understanding Ask yourself three things about any model in your admin: 1. Who can see "Delete selected" here — which `has_delete_permission()` answers `True`? 2. What else disappears with each row — which foreign keys cascade, and which are protected? 3. Does anything important live in `Model.delete()` that the bulk path would skip? If the third answer is yes, the fix is on the `ModelAdmin`, not in the model.