Improve instance form errors #173

Merged

tobru merged 3 commits from 164-keep-values-on-error into main

2025-09-12 07:21:30 +00:00

rixx commented

2025-09-03 23:04:05 +00:00

Member

ref #164

I was not able to reproduce the issue with the missing form values in either Firefox or Chrome by manually injecting an exception in the process, and from what I can tell, we are already doing the right thing in Django (using form_invalid() in the view when errors occur). I improved the error placement and logic a bit while looking at this, but not sure where to begin to reproduce the actual problem.

ref #164 I was not able to reproduce the issue with the missing form values in either Firefox or Chrome by manually injecting an exception in the process, and from what I can tell, we are already doing the right thing in Django (using `form_invalid()` in the view when errors occur). I improved the error placement and logic a bit while looking at this, but not sure where to begin to reproduce the actual problem.

tobru commented

2025-09-04 13:22:14 +00:00

Owner

Created a liitle screencast of what I observed, even with this PR

Screencast_20250904_152011.webm

2 MiB

rixx force-pushed 164-keep-values-on-error from f0b724f26a to 5933352f5f

2025-09-11 11:24:30 +00:00

Compare

rixx commented

2025-09-11 11:36:52 +00:00

Author

Member

The screencast shows you saving the form after entering only the name, which should be impossible now that the required field detection is fixed, right?

The fact that required fields are now listed correctly makes pretty hard to reproduce the problem, but it will still occur if the instance creation or server-side validation fails.

The problem seems to be with the spec.parameters.service.fqdn field, which the browser displays with its previously entered value, but on form submission, the browser sends a "[", which the server correctly rejects – and then, of course on the second page render with errors, the previous user input is missing, as it never made its way back to the server.

The screencast shows you saving the form after entering only the name, which should be impossible now that the required field detection is fixed, right? The fact that required fields are now listed correctly makes pretty hard to reproduce the problem, but it will still occur if the instance creation or server-side validation fails. The problem seems to be with the `spec.parameters.service.fqdn` field, which the browser *displays* with its previously entered value, but on form submission, the browser *sends* a `"["`, which the server correctly rejects – and then, of course on the second page render with errors, the previous user input is missing, as it never made its way back to the server.

rixx added 1 commit 2025-09-11 12:58:35 +00:00

Fix JSON re-parsing in re-rendered invalid form

Tests / test (push) Successful in 25s

Details

1a2a75880d

rixx commented

2025-09-11 12:59:33 +00:00

Author

Member

I think I have caught the bug – will require some hard reloads to make sure the new JavaScript is used. I may have gone a bit overboard in defending against it cropping up again, but better safe than sorry. Could you test the fix to see if it works for you aswell, @tobru ?

I *think* I have caught the bug – will require some hard reloads to make sure the new JavaScript is used. I may have gone a bit overboard in defending against it cropping up again, but better safe than sorry. Could you test the fix to see if it works for you aswell, @tobru ?