Inability to exclude a field based on a condition

[GeorgeHulpoi]

Link to reproduction

https://github.com/GeorgeHulpoi/payload-field-conditional-bug/tree/main

To Reproduce

1. Create a field with admin.condition based on a sibling data value.
2. Create hooks for beforeChange or afterRead where you return undefined if the admin.condition fails.
3. Check the database and the API response, it contains the old value instead of not being present in response.

Describe the Bug

Seems like the value undefined will fail this condition: https://github.com/payloadcms/payload/blob/master/src/fields/hooks/beforeChange/promise.ts#L80 and because of it, I can't manage to exclude a field from the database it nor API response.

Payload Version

^1.15.6

[jmikrut]

Hey @GeorgeHulpoi — you'll need to set the field to null if you'd like to remove its data. This is expected behavior. However, as a new feature, it's possible that we could check for the existence of keys, and if the property exists, and its value is undefined, we could send through undefined as you have anticipated.

Setting to null is the expected behavior here though. Thank you for bringing this up!

[GeorgeHulpoi]

Hey @GeorgeHulpoi — you'll need to set the field to null if you'd like to remove its data. This is expected behavior. However, as a new feature, it's possible that we could check for the existence of keys, and if the property exists, and its value is undefined, we could send through undefined as you have anticipated.

Setting to null is the expected behavior here though. Thank you for bringing this up!

@jmikrut Naturally, I tried null also, but it didn't remove it from the database. Seems like you update the document in the database with the null value, but this won't have the same effect as $unset.

Therefore, I don't know if this is the wanted result or is a bug, but the null values from the updated doc should be swapped into an $unset operation.

[jmikrut]

Hey @GeorgeHulpoi — well, we could certainly build a pattern to unset values that are found to be undefined which would be relevant to MongoDB specifically. Right now, this is intended though.

I will convert this into a feature request for MongoDB and we can monitor it there accordingly!