Skip to content

fix(ui): forward list filter to bulk actions when selecting all across pages - #17695

Open
luantaraschi wants to merge 1 commit into
payloadcms:mainfrom
luantaraschi:fix/list-selection-forward-where
Open

fix(ui): forward list filter to bulk actions when selecting all across pages#17695
luantaraschi wants to merge 1 commit into
payloadcms:mainfrom
luantaraschi:fix/list-selection-forward-where

Conversation

@luantaraschi

Copy link
Copy Markdown

Fixes #17670

What?

ListSelection accepts a where prop and forwards it to EditMany, PublishMany and UnpublishMany, but the two main list-view call sites never pass it. This PR forwards the URL where query from useListQuery() at both call sites.

Why?

When an editor filters a list, clicks "Select all N across pages" and then triggers a bulk action, the filter is dropped and the action hits every document matching only the action's base constraint.

The issue reports a concrete case: a collection filtered to 598 documents via ?where[pageType][equals]=atm, bulk Unpublish, and 1772 documents get unpublished instead.

Three things in the current code line up with that:

  1. views/List/ListSelection/index.tsx declares where?: Where and passes it to EditMany, PublishMany and UnpublishMany.
  2. views/List/GroupByHeader/index.tsx already passes where, so the prop is the intended contract — the two list-view call sites are the outliers.
  3. DeleteMany is unaffected because it uses baseWhere, derived from parseSearchParams(searchParams) inside ListSelection itself. That matches the reported symptom exactly: Delete respects the filter, Edit/Publish/Unpublish do not.

Manual row selection is also unaffected, because that path sends id IN [ids].

How?

Two call sites, both reading the same query.where the list view already uses:

  • views/List/ListHeader/index.tsx (desktop) — destructure query from useListQuery() and pass where={query?.where}.
  • views/List/index.client.tsx (smallBreak) — pass where={query?.where}; query was already destructured there for the hasWhereParam effect.

Added an e2e test in test/bulk-edit/e2e.spec.ts that creates three matching and three non-matching published posts, filters the list, selects all across pages, unpublishes, and asserts that the three non-matching documents are still published.

Testing performed

  • tsc --noEmit on packages/ui: no new errors introduced. I compared against a baseline run on unmodified main and the output is identical.

  • I was not able to run the e2e suite locally. pnpm install fails on Windows during postinstall: @vercel/git-hooks throws EPERM: symlink when creating .git/hooks/applypatch-msg, which aborts the lifecycle and leaves node_modules/.bin unpopulated. Completing the install with --ignore-scripts gets the workspace linked, but the dependent packages are then unbuilt, so tsc reports TS6305 across the package and the Playwright suite can't start.

    The new test follows the existing should unpublish many test in the same file and reuses addListFilter from test/__helpers/e2e/filters, but it has not been executed. Flagging that explicitly rather than implying otherwise — please have CI or a maintainer confirm it fails without the fix and passes with it.

Notes for the reviewer

query?.where is written defensively even though IListQueryContext.query is non-optional, to match the surrounding usage in index.client.tsx (hasWhereParam, the useEffect dependency) and in the ListQuery provider itself.

I did not touch HierarchyList/HierarchyListHeader, which also renders a selection component — it uses DocumentListSelection rather than this ListSelection, so it's a separate path and out of scope here.

…s pages

ListSelection accepts a `where` prop and forwards it to EditMany, PublishMany and
UnpublishMany, but the two list-view call sites never passed it. Selecting all
documents across pages under an active URL filter therefore applied bulk actions
to every document matching only the action's base constraint, ignoring the filter.

GroupByHeader already passes `where`, and DeleteMany is unaffected because it
derives baseWhere from the search params inside ListSelection itself — which is
why only Edit/Publish/Unpublish showed the bug.

Fixes payloadcms#17670
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: List view drops URL "where" filter on bulk Publish/Unpublish/Edit across pages

1 participant