Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[JENKINS-45387] Fix validation error displaying in setup wizard's "create first admin" form #3116
This PR resolves validation errors not being properly displayed in the setup wizard's "create first admin user" form. For that, it creates a new special account creation method in the security realm. In the frontend, it adapts the error handling to work.
Technical issue description
For (1), I extracted the validation logic in the realm into a new private method and the creation logic into another
For the frontend issues, I split the response handling into two methods. The success method does the same thing as before, just without the unnecessary parsing and with a slightly more meaningful error message.
The failure method now doesn't check the response for the error class any more and just displays it. The distinction didn't seem to be working, and seemed unnecessary to me. It also replaces the
I have not included automated tests for this change because I frankly don't think it's worth the effort for this type of change. To test the UI would require full-blown UI tests and checking the backend response for the error code would just be repeating the production code in a test. I have manually tested the changes in Chrome and Firefox on Arch Linux though.
To always start the setup wizard, I (locally and temporarily) added the
I have not run the full test suite on this and am waiting for the CI to do it for me. When I first set up the project, I accidentally ran it with
Proposed changelog entries
I'm looking forward to hear what you think!
Let's get this reviewed, merged.. released
I just ran into the same use
Note: No issue on the 2. try, when I retried filling out the empty form, with same values , except this time I also choose just a single word in the full name field (
Thanks for the comments @daniel-beck, haven't got to resolve these yet. (tomorrow?) From a quick look at the PR that created the merge conflict, the issue it solves seems quite similar to my one. I'll need to verify whether this PR is still necessary or the other one already resolved the issue.
Sorry for the delay! After some manual testing, I can confirm that #3164 fixes the frontend issue. However, the stack trace still appeared. I have rebased my commits on master, resolved the remaining code comments and tested the result to make sure the issue is still resolved.
I merged my frontend changes with the fix from #3164 and kept them in because I find it a lot cleaner to have separate callbacks for success and error.
I also squashed the code style commits because the rebase needed a force-push anyways.
@daniel-beck from what I saw when resolving the merge conflicts, it seems to fix the frontend issue (iirc the HTTP response and response DTO were confused when trying to display the error, and there was an issue with iframes). However, the stack trace still appeared (responses were still attempted to be sent twice on error), so this PR is still necessary. I had also done some splitting to the frontend code, which I kept as well. (also see my comment above #3116 (comment))