HIGH DATALOSS RISK: Multi Edit overrides field data with its "defaultValue"
Describe the Bug
this is quite a severe issue causing collection fields to reset to a defined "defaultValue" if you use the mass edit function from the UI
I discovered the bug when i selected 20 posts and changed the Status field in the UI. I noticed that the Date field data changed on all documents to the "defaultValue"
{
name: 'publishDate',
label: 'Publish Date',
type: 'date',
required: true,
defaultValue: () => new Date().toISOString(),
},
In this case the Mass Edit will override the existing field date value to a fresh new Date set in "defaultValue"
Link to the code that reproduces this issue
https://github.com/yonnic/payload-override-bug
Reproduction Steps
- Create a test collection with a field defining a defaultValue besides some other dummy fields.
- Generate a few dummy items in the Collection but make sure to not use the value set in "defaultValue"
- Mass Edit using the UI on some documents and apply changes to one of the dummy fields.
- Watch how the field having "defaultValue" gets reset.
https://github.com/user-attachments/assets/5e1721f1-db12-4916-97ba-f6d49ff54172
Which area(s) are affected? (Select all that apply)
Not sure
Environment Info
Binaries:
Node: 20.15.1
npm: 10.7.0
Yarn: 1.22.22
pnpm: 9.14.2
Relevant Packages:
payload: 3.2.1
next: 15.0.3
@payloadcms/db-mongodb: 3.2.1
@payloadcms/email-nodemailer: 3.2.1
@payloadcms/email-resend: 3.2.1
@payloadcms/graphql: 3.2.1
@payloadcms/next/utilities: 3.2.1
@payloadcms/payload-cloud: 3.2.1
@payloadcms/plugin-cloud-storage: 3.2.1
@payloadcms/richtext-lexical: 3.2.1
@payloadcms/storage-s3: 3.2.1
@payloadcms/translations: 3.2.1
@payloadcms/ui/shared: 3.2.1
react: 19.0.0-rc-02c0e824-20241028
react-dom: 19.0.0-rc-02c0e824-20241028
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.2.0: Fri Oct 25 20:27:42 PDT 2024; root:xnu-11215.60.400.0.1~11/RELEASE_ARM64_T6000
Available memory (MB): 65536
Available CPU cores: 10
Please add a reproduction in order for us to be able to investigate.
Depending on the quality of reproduction steps, this issue may be closed if no reproduction is provided.
Why was this issue marked with the invalid-reproduction label?
To be able to investigate, we need access to a reproduction to identify what triggered the issue. We prefer a link to a public GitHub repository created with create-payload-app@beta -t blank or a forked/branched version of this repository with tests added (more info in the reproduction-guide).
To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue. Ensure your reproduction does not depend on secrets, 3rd party registries, private dependencies, or any other data that cannot be made public. Avoid a reproduction including a whole monorepo (unless relevant to the issue). The easier it is to reproduce the issue, the quicker we can help.
Please test your reproduction against the latest version of Payload to make sure your issue has not already been fixed.
I added a link, why was it still marked?
Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.
Useful Resources
Hey @yonnic - thank you for catching this!
I just opened a PR to fix the issue - we'll get a release out for this asap!
🚀 This is included in version v3.6.0
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.