Value for radio not sent in hook/flow payload

[arladmin]

Describe the Bug

When creating a new item, if a Radio button's value is left unchanged (set to default), the payload in the Flow hook does not contain the field at all!

Related issue: directus/directus#24660

To Reproduce

1. Set a default value on a Radio field in a collection
2. Create a Directus Flow, for action items.create for the particular collection
3. Create new Item for that collection. Do not change the Radio field's value at all.
4. The Flow payload does not consist of the Radio field at all

The expectation is: a 'configuration' (default value being set for a field) done entirely within Directus should get implemented properly (properly = work first-class throughout Directus), without having to take into account how the DB deals with it (because that's sort of the whole point of Directus) [as indicated in responses to other similar issues]

Directus Version

v11.11.0

Hosting Strategy

Self-Hosted (Docker Image)

Database

No response

[linear]

CMS-1313 Value for radio not sent in hook/flow payload

[triagster]

Related issues:

• #24852

Was this useful? Use the reactions below to give feedback.

[ComfortablyCoding]

As mentioned in directus/directus#24660 this is expected behavior. The payload for the items.create event (filter or action) is expected to be the final payload submitted not the result of the insertion/update. It will therefor not contain any default values as that is the databases responsibility. If you wish to retrieve the created record data an additional query inside the hook is required.

As this looks to be a documentation issue I'll move it to the appropriate repo.

[linear]

EDU-484 Value for radio not sent in hook/flow payload

[arladmin]

As mentioned in directus/directus#24660 this is expected behavior. The payload for the items.create event (filter or action) is expected to be the final payload submitted not the result of the insertion/update. It will therefor not contain any default values as that is the databases responsibility. If you wish to retrieve the created record data an additional query inside the hook is required.

As this looks to be a documentation issue I'll move it to the appropriate repo.

@ComfortablyCoding
For a user filing in a form, a pre-filled (default) field is not a "database issue". It's equivalent to a conscious action of selecting/entering the value for any field in the form.

Consequently, the payload of the hook (user's form submission action) is expected to contain all of the data that the user has acted on, including any default values.

Additionally, i fail to understand why is this an issue even for the "Action" hook.

[ComfortablyCoding]

For a user filing in a form, a pre-filled (default) field is not a "database issue". It's equivalent to a conscious action of selecting/entering the value for any field in the form.

Consequently, the payload of the hook (user's form submission action) is expected to contain all of the data that the user has acted on, including any default values.

A database default value occurs due to the absence of a selection. The app displaying it with no selection is indicative what will be the result if a save occurs with no change/selection, this doesn't mean the value is included in the payload. If a default is intended, it's expected that the field will be omitted from the payload entirely.

Additionally, i fail to understand why is this an issue even for the "Action" hook.

As mentioned, these hooks are provided the payload, not the final saved result. Since default values are set by the database after submission, they aren't part of the payload and therefore won’t appear in any hook data.

In the case of item creation/insertion: a filter hook receives the raw, unmodified payload; an action hook receives a version of the payload that may have been modified by filter hooks and/or presets.

If you wish for defaults to be present in the action payload I would suggest utilizing field presets over db default values.