AAE-28918 Fix for start process button is enabled when required widgets are read only without value

[dthornton-hyl]

Please check if the PR fulfills these requirements

• [ x] The commit message follows our guidelines
• [ x] Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x")

• [ x] Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation
• Other... Please describe:

What is the current behaviour? (You can also link to an open issue here)
https://hyland.atlassian.net/browse/AAE-28918
Start button is enable if all fields are read-only and required. Clicking Start button will return validation error from BE.

What is the new behaviour?
Start button is disable if all fields are read only and required

Does this PR introduce a breaking change? (check one with "x")

• Yes
• [ x] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...

Other information:

[Copilot]

Pull request overview

Fixes start-process form validation so the Start button is not enabled when all required widgets are read-only but empty (avoids backend-side required validation errors).

Changes:

• Updates FormFieldModel.validate() to mark read-only + required + visible fields as invalid when their value is empty (even when the field type is not in the “validatable” list).
• Adds a small helper (isValueEmpty) to detect empty values across common value shapes.
• Expands unit tests to cover read-only required fields with/without values and hidden-field behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
lib/core/src/lib/form/components/widgets/core/form-field.model.ts	Adds read-only required empty-value validation to prevent enabling Start when required read-only fields are empty.
lib/core/src/lib/form/components/widgets/core/form-field.model.spec.ts	Adds/updates tests validating the new read-only required behavior and hidden-field exemption.

[sdonnell-hyland]

I'm surprised we don't have a isFieldOrParentHidden check here - if it is correct/valid to check for field visibility as part of isFieldValidatable I would probably refactor things a bit, but my next question is should we only be doing the required check validation for readonly fields, or should all validation be ran?

[sdonnell-hyland]

And personal opinion (I know you didn't write this code), but I would rename this something like shouldValidate instead of isFieldValidatable

[dthornton-hyl]

I will look into it. Will convert this to a draft PR for the time being.

[dthornton-hyl]

FormFieldTypes.isValidatableType just had one field type in it. So isFieldValidatable() was pretty much returning if a field was readOnly or not. Since want to validate either readOnly or not. Can pretty much do away with the isFieldValidatable() check.

The validator.validate() has checks to see if the field is validation is supported (so making the isFieldValidatable check not needed) and it also checks the isFieldOrParentHidden

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sdonnell-hyland]

I'm good with this change, but lets run it by product or the Automate Front End channel. It seems reasonable to me to require all fields to be valid regardless of being editable.

FormFieldTypes.isValidatableType is kind of an odd check to me because I don't know what a display-external-property type field is, which appears to be the only type it's checking for, but want to confirm the removal of that check was intentional?