fix(data_export): make collection export respect the active filter and sort - #953
Open
marianmoldovan wants to merge 1 commit into
Open
fix(data_export): make collection export respect the active filter and sort#953marianmoldovan wants to merge 1 commit into
marianmoldovan wants to merge 1 commit into
Conversation
…d sort
`doDownload` called `dataSource.fetchCollection` with only `path` and
`collection`, so exporting always dumped the whole collection regardless of the
filter or sort applied in the collection view. The filter and sort are now read
from the `tableController` that `CollectionActionsProps` already provides and
forwarded as `filter`, `orderBy` and `order`.
Default behaviour: the filtered and sorted set is exported. Because that
silently changes four-year-old behaviour, the export dialog gains an opt-out
switch ("Only export results matching the current filter/sort", default on).
It is only rendered when there is something to opt out of, i.e. a filter the
user applied themselves or an active sort, so the dialog is unchanged for
unfiltered collections.
`collection.forceFilter` is a data scoping constraint rather than a user
preference, so it is merged in unconditionally and takes precedence over the
table controller's filter values, matching the precedence FiltersDialog uses.
Since `useDataSourceTableController` already seeds `filterValues` from
`forceFilter` and refuses user changes while it is set, forced keys are
excluded when deciding whether to show the switch.
`searchString` is deliberately not forwarded: the Firestore delegate accepts it
in `FetchCollectionProps` but ignores it in `fetchCollection` (text search is
only implemented for `listenCollection`), so passing it would silently do
nothing.
Adds the `export_apply_filter_sort` key to `FireCMSTranslations` and all eight
locale files.
Fixes #297
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
marianmoldovan
requested review from
Copilot and
fgatti675
and removed request for
fgatti675
July 29, 2026 17:06
There was a problem hiding this comment.
Pull request overview
This PR fixes collection exports in @firecms/data_export so that exported results can respect the currently active table filter and sort (addressing #297), with a default-on opt-out toggle in the export dialog. It also adds the necessary i18n key across all core locales.
Changes:
- Pass
filter,orderBy, andorderintodataSource.fetchCollectionduring collection export, derived fromtableController(and always applyingforceFilter). - Add a default-on “Only export results matching the current filter/sort” toggle, shown only when a user-applied filter or any sort is active.
- Add the new
export_apply_filter_sorttranslation key toFireCMSTranslationsand all core locale files.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| packages/firecms_core/src/types/translations.ts | Adds export_apply_filter_sort to the typed translations contract. |
| packages/firecms_core/src/locales/en.ts | Adds English string for the new export toggle label. |
| packages/firecms_core/src/locales/de.ts | Adds German string for the new export toggle label. |
| packages/firecms_core/src/locales/es.ts | Adds Spanish string for the new export toggle label. |
| packages/firecms_core/src/locales/fr.ts | Adds French string for the new export toggle label. |
| packages/firecms_core/src/locales/hi.ts | Adds Hindi string for the new export toggle label. |
| packages/firecms_core/src/locales/it.ts | Adds Italian string for the new export toggle label. |
| packages/firecms_core/src/locales/pl.ts | Adds Polish string for the new export toggle label. |
| packages/firecms_core/src/locales/pt.ts | Adds Portuguese string for the new export toggle label. |
| packages/data_export/src/export/ExportCollectionAction.tsx | Implements filter/sort-aware export (plus forceFilter precedence) and adds the opt-out switch UI. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #297 — open since 2022.
The gap
doDownloadcalleddataSource.fetchCollection({ path, collection })with nofilter,orderByororder, so exports always returned the whole collection regardless of what the user was looking at. The plumbing already existed:FetchCollectionPropsaccepts those, and this component already receivestableController(which exposesfilterValuesandsortBy) viaCollectionActionsProps.UX decision
One opt-out switch, default ON: "Only export results matching the current filter/sort".
clear_filter_sort,no_results_filter_sort) instead of inventing terminology, and covers the filter-only and sort-only cases with one string.BooleanSwitchWithLabelswitches, same component and props shape.forceFilterChecked first, and it matters:
useDataSourceTableControlleralready seedsfilterValuesfromforceFilterand refuses user changes while it's set, sotableController.filterValuesalready contains it. Handling:forceFilteris spread in unconditionally, after the controller's values, so it always wins — matchingFiltersDialog.tsx.forceFilteronly; toggling on gives user filter +forceFilter.searchString— deliberately not covered, and here's whyThe Firestore delegate's
fetchCollectiondestructuressearchString, documents it in JSDoc, and then never passes it tobuildQuery. Text search is implemented only inlistenCollectionviaperformTextSearch. Wiring it into the export would silently do nothing.So a known remaining limitation: exporting while a text search is active still exports the unsearched set. That's a separate latent issue worth its own ticket (adjacent to #322/#571), not something to paper over here.
i18n
Every locale file is typed
FireCMSTranslations(not partial), so the new key had to be added to all 8 core locales — and thelabelprop is covered by the repo'si18next/no-literal-stringrule, so a bare literal wasn't an option. The guarantee was mutation-tested: deleting the key frompl.tsalone makestscfail with TS2741.Verification
pnpm --filter @firecms/data_export buildexits 0 (after rebuilding@firecms/core, whose checked-indistonmainis stale — a pre-existing condition, untouched here).BasicExportAction.tsxneeds no change: it receives already-materialised data and has nofetchCollectioncall.Gap
The two extracted helpers (
hasUserFilterOrSort,resolveExportFilterAndSort) are pure and trivially testable but module-private and uncovered. Jest is already configured indata_export, so a spec would be cheap — the helpers just need exporting. The dialog rendering and the actual filtered download are unverified at runtime.🤖 Generated with Claude Code