Dropdown labels missing in email notifications when using dynamically overridden options via setFieldSettings

[jedso]

Describe the bug

So I originally came across this issue trying to override Dropdown export values via Dropdown::EVENT_MODIFY_VALUE_FOR_EXPORT event to always export labels instead of Dropdown values. Checking the Dropdown field with $submission->getFieldValues(), I noticed for Dropdown fields that had had their options dynamically overridden with setFieldSettings, labels would always be null. E.g.

{% for i in 1..3 %}
    {% set sessionOptions = sessionOptions|merge([{
        label: 'Option ' ~ i,
        value: i
    }]) %}
{% endfor %}

{% do form.setFieldSettings('sessionSelect', {
    options: sessionOptions
}) %}

Then out of curiosity, I checked to see if email notifications handled showing these dynamic labels properly, and alas it shows up as empty when displaying the label in the notification.

In the submission itself, these dynamic labels show up fine so it seems to be an issue with it not being exposed in notification/export contexts.

Steps to reproduce

1. Create a basic form with 1 Dropdown field. Give it a handle of sessionSelect.
2. In the field settings, make sure the field is included in email notifications and is set to use its 'Label' as the notification value.
3. Setup an email notification that includes the form field in its body.
4. In the template where the Form is rendered, copy the Twig loop above to set dynamic Dropdown options.
5. Submit the form.
6. Observe how email notification does not display the label in its body after being sent.

Form settings

• Multi-page form: No
• Submission Method: Page Reload (or Ajax, same result)
• Client-side Validation: No
• Custom Form Templates: No

Craft CMS version

5.5.10

Plugin version

3.0.20

Multi-site?

No

Additional context

No response

[engram-design]

What's your content for the email notification? I was just testing the following:

I can confirm the latter option isn't working correctly, but the first is.

Just wanted to confirm?

[jedso]

Ah my bad for not specifying, this was for All Form Fields. However, interestingly I'm not experiencing the same as you in that screenshot. With that same email content, the submission notification ends up looking like this for me (no label in the first):

I thought for a second that maybe I still had some custom module logic that might be messing with this, but even after disabling anything custom, I consistently get the same results as the screenshot above. Is there anything in particular you can think of that may be causing this? I'm using a MariaDB instance, if that matters.

[engram-design]

Thanks for clarifying that, that does seem odd. Seems like it's not applying the snapshot data (the saved dynamic options) somehow. I'll continue looking into it to try and replicate things.

[jedso]

So it feels a bit messy, but as a temporary workaround I've added this event hook to always use export labels for dropdowns that have snapshot data:

        Event::on(
            Dropdown::class,
            Dropdown::EVENT_MODIFY_VALUE_FOR_EXPORT,
            function (ModifyFieldValueEvent $event) {
                $fieldHandle = $event->field->handle;
                $snapshotData = $event->submission->snapshot;

                if (!empty($snapshotData['fields'][$fieldHandle]['options'])) {
                    $options = $snapshotData['fields'][$fieldHandle]['options'];

                    // Find label for the selected value
                    foreach ($options as $option) {
                        if (isset($option['value']) && $option['value'] == $event->value) {
                            $event->value = $option['label'];
                        }
                    }
                }
            }
        );

I was intending to do the same for Dropdown::EVENT_MODIFY_VALUE_FOR_EMAIL, but it seems like this event is never firing for me. My debug breakpoints aren't ever being hit. I noticed someone reporting a similar issue in (#800), but it seems like it was for Formie v1.x.x. Is this event supposed to work in v3.x.x?