OneIdentity / IdentityManager.Imx

HTML5 source code for Identity Manager web apps
Other
26 stars 107 forks source link

Bypass validation script on Request Details sidesheet #120

Closed NielsDeGroot closed 4 months ago

NielsDeGroot commented 4 months ago

I've configered a 'Request property' with User Prompt, mandatory parameter = yes and the following 'Validation script'.

If String.Equals(Convert.ToString(Value), "Exception", StringComparison.OrdinalIgnoreCase) Then Throw New ViException("Validation script exception!", ExceptionRelevance.EndUser) End If

Now when I select the product from the productlist, type "Exception" in the form and click on 'Apply'. I'm allowed to 'Submit' the product to the shopping cart. In the logging I can see Error: [{"Message":"Validation script exception!","Number":0}]

a

Only when I type something else first like "test" (click on TAB) and then type in "Exception" the error message is visiblible shown and the [Apply] and [Submit] buttons are greyed out.

b c

Regards, Niels

Mathnstein commented 4 months ago

Hi @NielsDeGroot , looking into this I'm not sure this is a bug at all but definitely not within the scope of the web frontend. This issue appears to be coming from the backend.

Please open up a support case around this for the api/backend to look into this

asattler commented 4 months ago

Hi Cody, are you sure about this? As far as I know the reason for this behavior is based on the configued update-behavior on the editors OI has implemented. It's set to onBlur. public readonly control = new UntypedFormControl(undefined, { updateOn: 'blur' }); https://github.com/OneIdentity/IdentityManager.Imx/blob/v92/imxweb/projects/qbm/src/lib/cdr/edit-default/edit-default.component.ts#L41C2-L41C85

So question is, if the web is intended to work like this or not. For sure there are pros & cons for the updateOn-values. A workaround might be, to modify the behavior of the submit-button. E.g. re-verify everything is fine now that the button is clicked (and so the field is blurred).

BR

Andreas

Mathnstein commented 4 months ago

Hi @asattler, Ah my misunderstanding on the issue presented here. Yes we do intend for the form fields to be based onblur, but there is a weird state happening here where we shouldn't allow for the apply button to be active until the field has been validated.

I suspect that can be done with just a MinLen but regardless I'll open a ticket.

@NielsDeGroot apologies on the misunderstanding.

Mathnstein commented 4 months ago

Created an internal ticket: 447895

gitpm commented 4 months ago

Hi @NielsDeGroot the question is why you prefer { updateOn: 'blur' } for form fields?

For a optimal ux-behaviour I usually prefer { updateOn: 'change' } for standard editable FormControls in order to efficently use MinLen/MaxLen/Date/Regex-Validators with a realtime feedback to the user (also concerning effects like e.g. enabling / disabling buttons)

Only for readonly-lookup-controls I usually used { updateOn: 'submit' }. So the content is validated before sending the content to the server. The reason is, that the content of the lookup-control should be controlled by the lookup-provider itself in first place.

Maybe this helps

Mathnstein commented 4 months ago

@gitpm In many cases the communication with the server is happening more frequently and not on-submit. Most CDR editors have secondary effects that require server results. onBlur is a method to prevent false interim states from occurring (i.e I've lost other column options due to having not finished typing).

In this case the script has to be run at some point, do we want that to happen continuously or onBlur - and I would argue onBlur is sufficient.