Skip to content

fix(plugin-import-export): respect defaultVersionStatus/draft on update-mode imports#17426

Open
jaccovdalfsen wants to merge 1 commit into
payloadcms:mainfrom
jaccovdalfsen:fix/plugin-import-export-draft-status-on-update
Open

fix(plugin-import-export): respect defaultVersionStatus/draft on update-mode imports#17426
jaccovdalfsen wants to merge 1 commit into
payloadcms:mainfrom
jaccovdalfsen:fix/plugin-import-export-draft-status-on-update

Conversation

@jaccovdalfsen

Copy link
Copy Markdown

Problem

When importing into a collection with versions.drafts enabled using importMode: 'update' or 'upsert' against an existing document, processImportBatch (in packages/plugin-import-export/src/import/batchProcessor.ts) never passed draft to payload.update(), and never applied the plugin's defaultVersionStatus fallback — that fallback only existed on the sibling create branch.

Effect: re-importing a document (e.g. one exported without its _status column) always overwrote the currently published version live, even when defaultVersionStatus: 'draft' was configured, because Payload core's update operation only saves a draft when the draft argument is explicitly passed (isSavingDraft = Boolean(draftArg && ...) in packages/payload/src/collections/operations/utilities/update.ts).

Root cause

The importMode === 'update' || importMode === 'upsert' branch's "existing document found" case built updateData but skipped the _status/draftOption resolution that the create branch (and the upsert-creates-new branch) already do, and never forwarded draft to either of the two req.payload.update() calls that follow (the multi-locale branch and the non-multi-locale branch).

Fix

Mirrors the existing create-mode logic: resolves statusValue = updateData._status || options.defaultVersionStatus, derives draftOption, sets updateData._status, and passes draft: draftOption to both payload.update() calls.

Tests

  • Added a regression test under the posts-imports-only describe block in test/plugin-import-export/int.spec.ts (that collection already configures defaultVersionStatus: 'draft' with versions.drafts: true). It creates a published doc, updates it via an update-mode import with a row that omits _status, and asserts the published version is untouched while a new draft version holds the updated data.
  • Added published-version assertions to the existing should handle upsert mode correctly test to cover the published-default-status path (pages has no defaultVersionStatus override, so it should continue to publish directly — confirming no regression there).
  • Full scoped suite (pnpm run test:int plugin-import-export) passes: 238 passed, 5 skipped, 0 failed.

Test plan

  • pnpm run test:int plugin-import-export passes locally (MongoDB)
  • tsc --noEmit / build of plugin-import-export succeeds
  • No changes to unrelated create-mode or explicit-_status-in-row behavior

🤖 Generated with Claude Code

…te-mode imports

processImportBatch never passed draft to payload.update() (or applied the
defaultVersionStatus fallback) on the update-existing-doc path for
importMode: 'update'/'upsert', so re-importing a versioned document always
overwrote the published version live regardless of defaultVersionStatus or
an incoming draft _status, since core's update operation only saves a draft
when the draft argument is explicitly passed.

Adds a regression test under the posts-imports-only suite (which already
configures defaultVersionStatus: 'draft') asserting the published version
is preserved and the update lands in a new draft version, plus published-
version assertions on the existing upsert-mode test to cover the published
default-status path.
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