Modal: Default buttons do not remain disabled in modals that contain timepickers
Describe the bug When a modal button with the isDefault option is disabled, and the modal has a timepicker, it does not remain disabled, even if validate is set to false.
To Reproduce Steps to reproduce the behavior:
- In the Enterprise-NG project, replace openNested() in the modal-dialog.demo.ts service with the following:
openNested() {
const dialogRef = this.modalService
.modal<NestedModalDialogComponent>(NestedModalDialogComponent, this.placeholder)
.buttons(
[{
text: 'Cancel', click: () => {
dialogRef.close();
}
},
{
text: 'Submit', click: () => {
dialogRef.close();
}, isDefault: true,
validate: false
}])
.open()
.afterOpen((_: any, ref: SohoModalDialogRef<FullSizeModalDialogComponent>) => {
(ref as any).buttonsetAPI.at(0).disabled = true;
(ref as any).buttonsetAPI.at(1).disabled = true;
return true;
})
}
- replace nested-modal-dialog.component.html with a timepicker
<input soho-timepicker/>
- Open the nested modal and click anywhere inside the modal.
- Notice that Cancel, which is not the Default button, is still disabled, while Submit is not disabled.
Expected behavior Buttons should remain disabled. It seems like setting validate: false should prevent the modal manipulating the buttons.
Version -ids-enterprise-ng: [v13.2.1]
Platform
- OS Version: Windows 10
- Browser Name: Chrome
- Browser Version: Version 100.0.4896.75 (Official Build) (64-bit)
Did not have time to make a fullly working example. But one workaround you could try is to add the class no-validation to the buttons. This should skip the logic of the validation effecting button states. Also wondering if validate is needed on both buttons (i think the logic is saying it only works on the primary).
The relevant code is here https://github.com/infor-design/enterprise/blob/main/src/components/modal/modal.js#L446
[{
text: 'Cancel', click: () => {
dialogRef.close();
},
validate: false,
cssClass: 'no-validation'
},
{
text: 'Submit', click: () => {
dialogRef.close();
},
isDefault: true,
validate: false,
cssClass: 'no-validation'
}])
My hunch is you just need the class as well so it skips the logic later when the validation is firing.
@lbursey-infor does the workaround work? Does this still need a fix? We can slide this in if needed
@tmcconechy I haven't given the workaround to QA yet but it looks like it works
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
This issue was closed because it has been inactive for 14 days since being marked as stale.