Skip to content

fix(ui): preserve URL where filter on bulk publish/unpublish/edit#16570

Open
dawndarkness wants to merge 1 commit into
payloadcms:mainfrom
dawndarkness:fix/list-view-where-prop-bulk-actions
Open

fix(ui): preserve URL where filter on bulk publish/unpublish/edit#16570
dawndarkness wants to merge 1 commit into
payloadcms:mainfrom
dawndarkness:fix/list-view-where-prop-bulk-actions

Conversation

@dawndarkness

@dawndarkness dawndarkness commented May 11, 2026

Copy link
Copy Markdown

What?

@payloadcms/ui List view drops the URL where filter when an editor clicks "Select all N across pages" and then triggers a bulk action (Publish / Unpublish / Edit). The outbound PATCH request hits every document matching the action's base constraint (e.g. _status != draft for Unpublish), ignoring the filter the user had applied.

Concrete impact: filter to a subset of a collection (e.g.?where[pageType][equals]=atm, 598 docs), select all across pages, bulk Unpublish → request unpublishes all published docs in the collection (e.g. 1772), not just the filtered 598.

Manual row ticks were unaffected because that path sends id IN [ids]. Search-only (?search=) was also unaffected because search propagates through a separate code path. Only the structured ?where[...] URL param was being dropped.

Why?

Both packages/ui/src/views/List/index.tsx (smallBreak path) and packages/ui/src/views/List/ListHeader/index.tsx (desktop path) rendered <ListSelection> without forwarding the URL where from useListQuery(). Everything downstream was already wired correctly:

  • views/List/ListSelection/index.tsx accepts where and forwards it to EditMany_v4, PublishMany_v4, UnpublishMany_v4.

  • Each drawer merges the prop into its base constraint via combineWhereConstraints.

  • DeleteMany independently reads URL where via parseSearchParams(searchParams)?.where and was unaffected.

    The missing wiring was in the parent List views (DefaultListView and CollectionListHeader).

How?

Destructure query from useListQuery() in both DefaultListView (smallBreak path, packages/ui/src/views/List/index.tsx) and CollectionListHeader (desktop path, packages/ui/src/views/List/ListHeader/index.tsx), and pass query?.where into <ListSelection> at both sites.

Without the ListHeader wiring, PublishMany / EditMany masked the gap via their own parseSearchParams(searchParams)?.where fallback; UnpublishMany has no such fallback, so the bug was only visible on the unpublish path.

Adds three Playwright E2E tests in test/bulk-edit/e2e.spec.ts (Bulk Edit > preserves URL where filter on bulk actions across pages) that:

  1. Seed 6 filtered + 6 unfiltered docs (exceeds default page limit of 5, forces the cross-page selection button). Seeds set _status: 'published' explicitly — payload.create does NOT default to published for versioned collections (the _status field's defaultValue is 'draft' in versions/baseFields.ts), so a draft: false arg alone leaves the doc as draft.
  2. Navigate with ?where[and][0][title][like]=....
  3. Select-all + select-all-across-pages.
  4. Trigger bulk Unpublish / Publish / Edit.
  5. Assert via the Payload API that only filtered docs changed and the unfiltered set is untouched.

The existing "filters and across pages" coverage in this file uses the search
bar (?search=), which propagates separately, so it never exercised this code
path.

Refs #16325 (same root cause, framed there as a multi-tenant plugin bug).

The List view did not forward useListQuery()'s `where` to <ListSelection>,
  so Select-all-N + bulk Publish/Unpublish/Edit dropped the filter and hit
  every doc matching the action's base constraint.

Pass query?.where into <ListSelection>. Downstream merging via combineWhereConstraints already handles it. Adds E2E coverage.

Refs payloadcms#16325
@dawndarkness dawndarkness force-pushed the fix/list-view-where-prop-bulk-actions branch from 70ecfa3 to d8a9231 Compare May 29, 2026 03:20
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.

1 participant