Replies: 2 comments 1 reply
-
Is there a reason that a disabled field should be required? Of course it’s possible to configure a field like that, but without the user being able to provide a value for the field (because it’s disabled) that really only leaves being able to programmatically populate the field value, or give it a default. In that case, if you’re marking the field as required, then it’s up to you to provide a value for it, and if you don’t, then you’re not following your own form logic. Happy to entertain this, but my immediate feeling is that it’s more a misconfiguration, but I know it’s a similar case to conditional fields. |
Beta Was this translation helpful? Give feedback.
-
So our use case may be an odd one, but the goal is to have fields for internal use by customer service team members on a form's submissions. I'd like those fields to be required when editing a submission in the CP (but not the front end form) so that the CS team have to enter a value before changing the submission status and saving. This ensures that certain data is available when running some automated processes triggered by the status change. I can definitely see that this logic probably shouldn't be the default behavior, but it would be nice if something like this were available. If there's a better way to accomplish this, please let me know! |
Beta Was this translation helpful? Give feedback.
-
Right now, if a field's visibility is set to Disabled and it's set as a required field, it will produce an error when submitted from the front end because the field has no value. Skipping validation for these disabled fields would be consistent with the behavior for conditionally hidden fields and would allow the disabled fields to be used for internal purposes while still making it required.
Beta Was this translation helpful? Give feedback.
All reactions