Export functionality loses admin filter context when using admin actions

[uunbound]

Describe the bug
When using the export functionality through admin actions (selecting multiple records and exporting), the export process loses all applied admin filters. This results in exports containing records that don't match the filtered changelist view, leading to data inconsistency and incorrect exports.

To Reproduce
Steps to reproduce the behavior:

1. Go to any Django admin changelist that uses ExportActionMixin
2. Apply filters to narrow down the results
3. Select multiple records from the filtered results using checkboxes
4. Choose "Export selected [model]" from the action dropdown
5. See that the export form appears but the exported data ignores all applied filters
6. Result: Export contains records that don't match the filtered view

Versions (please complete the following information):

• Django Import Export: 4.0.0+ (issue introduced in v4.0.0)
• Python 3.8+
• Django 4.2+

Expected behavior
Exports should respect all applied admin filters and only export records that match the current filtered view, maintaining consistency between what users see in the changelist and what gets exported. This was the behavior in django-import-export versions prior to v4.0.0.

Additional context
The export form URL ("export_url" in the context) doesn't include the query parameters necessary for the export queryset to correctly narrow down the results. When the export form is submitted, it lacks the filter context (like ?date=2024-01-01&status=active) that was present in the original changelist view, causing the export to process the unfiltered dataset.

[matthewhegarty]

Thanks for raising. I can't reproduce this in the test app because when I apply filters and export via the action menu only the filtered and selected items are exported, which is the expected behaviour.

The export form URL ("export_url" in the context) doesn't include the query parameters necessary for the export queryset to correctly narrow down the results.

This is correct but the export process does retain the elements which have been selected, so the end result is that the selected rows appear in the export.

Am I missing something? Can you give me more guidance on how to reproduce?

Here are a couple of screenshots of my exporting in v4.

1. I filter on author 'Ian Fleming', which selects 2 items.
2. I select one or both and export, and the expected items appear in the export confirm page.
3. I click export and the expected items appear in the output.

If it helps this setting disables the confirmation screen.

[uunbound]

@matthewhegarty this problem seems to surface only when the base queryset of the admin class depends on query parameters (in my case, a custom date filter). If the queryset does not rely on query params, the issue does not appear.

In other words, when the changelist query params are required to construct the queryset, the absence of those params in the export form action causes get_export_queryset to return the wrong queryset, leading to empty exports.

Hope this makes it clear for you.

[matthewhegarty]

From your description it sounds like you have custom code to read filter params from the querystring and use them in construction of the queryset? Please correct me if I'm wrong.

Is it possible you can provide steps to reproduce in the example app?

[uunbound]

My FxRate model changelist queryset is customized to always return the latest records for a given date, using the following:

FxRate.objects.filter(date__lte=date).order_by("currency", "-date").distinct("currency")

By default, if the user hasn’t selected a date, the custom date filter applies today's date, so the changelist URL has no date param. That same URL (without a date param) is passed through get_export_queryset, which then builds the base queryset containing only the latest distinct records per currency.

The issue arises when a user explicitly selects a date via the admin date filter and then chooses records to export. Although those record IDs are correctly included as hidden fields in the export form, they may not be present in the base queryset that get_export_queryset reconstructs, due to the nature of the queryset above (which only keeps the latest distinct records per currency). As a result, some or all of the selected records may be missing from the export output.

In other words, the problem is not with custom code reading query params, but with the situation where the changelist queryset is implicitly filtered by default (no date param) versus explicitly filtered (with a date param).

[MatthiasGi]

The problem seems to correlate with custom filters that overwrite the default queryset. I.e. the queryset-method of the admin.SimpleListFilter returns a cropped list if the value is None.

To fix this issue, I was able to overwrite the get_export_queryset-method:

django-import-export/import_export/admin.py

Line 644 in aaeeb11

def get_export_queryset(self, request):

I'm simply using the default queryset function of the ModelAdmin:

def get_export_queryset(self, request):
    return self.get_queryset(request)

Unfortunately I'm not sure if this destroys some other feature, but for me until now it seems to be working. Feel free to try it for yourself.

[matthewhegarty]

I'm still confused trying to figure out what is going on. Can anyone give me steps to reproduce this using the example app?

[MatthiasGi]

Sure thing! Let's assume a custom filter for the Book model. We want two options only and no "all" option and apply it to the BookAdmin. E.g. in the admin.py:

class AuthorBirthdayListFilter(admin.SimpleListFilter):
    title = "author's birthday"
    parameter_name = "birthday"

    def lookups(self, request, model_admin):
        return (
            (None, "before 1920"),
            ("after", "after 1920"),
        )

    def choices(self, cl):
        for lookup, title in self.lookup_choices:
            yield {
                "selected": self.value() == lookup,
                "query_string": cl.get_query_string({self.parameter_name: lookup}, []),
                "display": title,
            }

    def queryset(self, request, queryset):
        if self.value() is None:
            return queryset.filter(author__birthday__year__lt=1920)
        if self.value() == "after":
            return queryset.filter(author__birthday__year__gte=1920)

@admin.register(Book)
class BookAdmin(ExportActionModelAdmin):
    list_display = ("name", "author", "added")
    list_filter = [AuthorBirthdayListFilter, "categories", "author"]
    resource_class = BookResource
    change_list_template = "core/admin/change_list.html"

Now try to select the non-default option, birthday after 1920 and try to export these. I'm now confronted with an error "not a valid option: 11" - which is the id of one of the corresponding books. In my production environment instead I get an empty table. My idea of the source of the problem is, that the id of this book isn't included in the get_export_queryset result which leads to a mismatch between the hidden input's value and the queryset.

Edit: Just to be sure: This only happens when exporting via the admin action!

[MatthiasGi]

Unfortunately I'm not sure if this destroys some other feature, but for me until now it seems to be working. Feel free to try it for yourself.

Actually this leads to a problem when exporting the whole page, as the included entities aren't selected accordingly. A quick (and admittedly dirty) fix could be:

def get_export_queryset(self, request):
    if request.POST and "export_items" in request.POST:
        return self.get_queryset(request)
    return super().get_export_queryset(request)

[matthewhegarty]

Thanks - I will take a look

[matthewhegarty]

Thanks for providing the test case - this helps a lot.

The issue is that the filter is not preserved in the query string in v4 because we direct to the 'confirm' screen (as the OP states). The issue doesn't show up in the regular workflow because the export confirm page stores the ids of the elements to be exported. Therefore you only see the issue if you depend on the query string parameters (i.e. in a custom query).

Setting the skip_export_form_from_action is a workaround because the parameters are preserved in this case. This is similar to the v3 behaviour which doesn't have an export 'confirm' screen.

[MatthiasGi]

You're right, this allows exporting the selected rows. But this way the user won't be able to select the columns to export and the data format. :-(

[matthewhegarty]

Sure - am working on a fix at present