Set required setting of a field in twig

[JulieVelghe]

Hi all,
I was wondering if it is possible to override the required setting of a field (specifically an upload-field).
I have a form that is being used to create or update a portfolio entry. When there isn't an id-parameter, the form concers a new entry and some fields are required.
When there is an id-parameter, the form gets prefilled and the entry gets updated. I would like to make some of the file-upload field non-mandatory, to prevent the user from having to upload the same file again.
Any idea how I could do this? I've tried:

    {% do form.setFieldSettings('workFeaturedAudio', {
        'required': 'false'
        })
    %}

But that doesn't seem to work, as the field still ends up being required.

And an additional question, how do I then make sure that, when no new file is being provided, the file in the entry remains as is?
In the past, when we tried setting the file-field to optional. But leaving it empty would result in the file being removed from the entry. We would like to avoid that, and simply keep the existing file in the entry when no new one is being provided in the form.

[engram-design]

Using setFieldSettings() to change the required state should work. I believe It's an issue if you're passing a string 'false' instead of just false.

{% do form.setFieldSettings('workFeaturedAudio', {
    required: true,
}) %}

{% do form.setFieldSettings('workFeaturedAudio', {
    required: false,
}) %}

Both the above work on my end.

As for File Upload fields, they're a little special because of how the browser handles <input type="file"> fields. They can't be populated with a value, so Formie will check if you've actually included a value, and if not, won't touch already-uploaded files. Unlike other, similar fields like Element fields, if you were to submit the form with no values selected, but have previously selected them and stored against the submission - they'll be cleared.

But it sounds like you might also be hooking Formie up to an Entry integration - is that correct? I just want to ensure that we have our submission (the Formie side) and entry (the Craft side) terminology correct.

[JulieVelghe]

@engram-design problem is, the code is not even getting in the payload event. I'm getting the error that is in my comment above, and the payload event doesn't seem to be triggered.

[engram-design]

Ah right, it's probably not getting to that stage yet, and it's failing on form submission. But don't forget that payload event is run in the context of a queue (by default) so it might be difficult to debug.

But, if you're sure that it's not reaching that far, I was pondering whether you could use Formie's conditionals to show/hide the field based on your logic. Even if that's populating a hidden field, which the File Upload field references in its conditions. A required hidden field will not be required, so in the form builder you could have the File Upload field set to required, but conditionally hidden.

Otherwise, I'll have to spin up an example and dive in. I'm probably not surprised there's issues programmatically changing the required state on the fly, so I'll have to take a deeper look into solutions.

[JulieVelghe]

@engram-design I don't think hidding the field is a usefull thing to do in my case. Because a user should be able to select another file, in case they want to update that portfolio-entry. But it shouldn't be mandatory, if, let's say, they only want to update a description field.
And in case it is a new entry (the code knows this because of a hidden field that gets populated), then the file-field should be mandatory.

[JulieVelghe]

@engram-design using your proposition of hidding the field might be a route. I've added a checkbox to ask the user if he/she want to upload a different file. If unchecked, the file upload field is not shown in the form, and I can save the form, the entry gets updated (I tried with a description field), but the linked file in the entry remained the same. Exactly what I wanted.
I'll have to do some more tests, but this might be a workable solution.

[engram-design]

Yeah that might be a nice alternative. This also goes without saying that one of the core issues here is the native <input type="file"> element being extremely limited in these sorts of things, which will be addressed in #133