[BUG] Date/Time Component Fails to Save When 'noeval' Property is Set to True
Environment
When using the noeval property set to true in the component within an Angular project, the Date/Time component fails to save. This issue occurs consistently and prevents the proper saving of the form. An error alert is shown with the message: "Please fix the following errors before submitting. Disable specific dates or dates by range: custom." The error is shown in the attached screenshot. However, the form saves without the error alert if noeval is set to false.
- Hosting type
- [ ] Form.io
- [x] Local deployment
- Version:
5.3.0
- Version:
- Formio.js version:
4.19.2 - Frontend framework: Angular
- Browser: Chrome
- Browser version:
Steps to Reproduce
- Create a form using the form builder in an Angular project.
- Drag and drop a Date/Time component into the form.
- Go to the Date section of the Date/Time component.
- Enter the date you want to exclude in the 'Disable specific dates or dates by range' field or leave it blank.
- Click Save on the preview screen on the right.
Expected behavior
The Date/Time component should save, even when the noeval property is set to true.
Observed behavior
The Date/Time component does not save, when you click save, an error alert is displayed with the message: "Please fix the following errors before submitting. Disable specific dates or dates by range: custom."
Code Implementation
<form-builder [form]="form" (change)="change()" [options]="formOptions" [noeval]="true"></form-builder>
Screenshot
Additional Information:
Workaround: When the noeval property is set to false, the form saves without any error alerts.
Rolling back to Formio.js version 4.15.1 seems to work without encountering this issue.
Thank you for the information you have provided. Could you please share a video example, or a JSFiddle to further investigate this?
Hi @Sidiro23
Im also able to reproduce this, here is a gif that will highlight the error that comes up
Thank you for taking the time to report this issue. A ticket has been created (FIO-8625) to resolve this issue.
After review, we don't expect to resource a developer to investigate this in the near future but would be happy to review any contributions to resolve this behavior.