-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: rework newpasswd view for CLI #394
Conversation
Personally I think showing two fields is not bad once one has been filled and being able to go back and forth to fix or change them (for example you want to add a final char to both forms). |
Yeah but in this case assuming the new password is invalid for any reason, the form will be cleared on submit so the user would have to start from scratch again. So as of right now it's more of a visual helper to see if the password and the confirmation are of the same length. |
I'd like to keep the two input fields. I'm not sure if we can add "prefix" labels to the input fields, but it would be nice if there was something like:
And, I agree, clearing the entire form if the entries don't match is a bit annoying, so maybe clear only the confirmation input and the error message? |
a60c812
to
f55cc82
Compare
Done, I've changed the prompt/prefix for the fields. This definitely looks cleaner.
I opted against doing this in the end as I don't think it adds a lot of value (other unix tools don't really do this and I think we should mimic their behavior for the most part). I've rebased the PR on top of Marco's work since it touched similar parts of the codebase. If I get the green light on the implementation I can start updating the tests :). |
UI side looks good to me, the only thing I'd probably move the fields to new line so that they have the same padding and it's easier to compare the length E.g.:
Also not sure if having a way to go back to the previous field where the second is active could be convenient, as now to correct one need to cancel the confirmation request. So maybe making |
f55cc82
to
88547e5
Compare
Instead of showing both prompts from the get-go, and having Enter submit the form straight away (and only being able to navigate through it with Tab), such as: Enter your new password > **** > We now render a single input if the user has just been shown the form, with an updated prompt: Enter your new password New password: > **** When pressing Enter -- provided that the password passes our quality checks -- the form changes to: Enter your new password (confirm) New password: > **** Confirm password: > **** This makes it clearer that we want the user to re-type their password. As a result, Tab navigation is no longer supported in non-skippable views, and the form can only be advanced by pressing Enter. For skippable views (i.e. with a button), Tab only works if the password is not filled in. This avoids opening a can of worms regarding to what fields we should be showing or not based on whether password fields are filled in. Thus, the skippable experience becomes: Enter your new password (3 days until mandatory) New password: > [ Skip ] // Focusable and Enter your new password (3 days until mandatory) New password: > ***** [ Skip ] // No longer focusable, have to finish filling in the form // (or clear it) Otherwise, I believe we should keep the form as simple as possible, without the possibility of jumping back to the previous password field once it was filled in, at the sake of improved maintainability. Fixes #365 / UDENG-3112
Mostly replacing Tab with Enter, and removing some redundant Tabs.
The error from pwquality is a bit different so we need to refresh the relevant golden files.
88547e5
to
9332177
Compare
Alright, CI passed so this is ready for a review! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #394 +/- ##
==========================================
- Coverage 85.31% 84.37% -0.95%
==========================================
Files 76 77 +1
Lines 6161 6686 +525
Branches 75 75
==========================================
+ Hits 5256 5641 +385
- Misses 642 733 +91
- Partials 263 312 +49 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good from my side, thanks!
Maybe we should consider making the also native interface similar to this when asking for secret, but that's indeed not for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the bubble tea related code and I didn’t spot anything special :) You are the real bubbletea master anyway! Well done as usual :)
Instead of showing both prompts from the get-go, and having
Enter
submit the form straight away (and only being able to navigate through it withTab
), such as:We now render a single input if the user has just been shown the form, with an updated prompt:
When pressing
Enter
-- provided that the password passes our quality checks -- the form changes to:This makes it clearer that we want the user to re-type their password. As a result,
Tab
navigation is no longer supported in non-skippable views, and the form can only be advanced by pressingEnter
.For skippable views (i.e. with a button),
Tab
(andShift-Tab
) only works if the password is not filled in. This avoids opening a can of worms regarding to what fields we should be showing or not based on whether password fields are filled in. Thus, the skippable experience becomes:and
Otherwise, I believe we should keep the form as simple as possible, without the possibility of jumping back to the previous password field once it was filled in, at the sake of improved maintainability.
Fixes #365 / UDENG-3112