-
Notifications
You must be signed in to change notification settings - Fork 354
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: webui create user prompts for password [DET-10221] #9240
feat: webui create user prompts for password [DET-10221] #9240
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9240 +/- ##
========================================
Coverage 44.60% 44.61%
========================================
Files 1273 1274 +1
Lines 155831 155942 +111
Branches 2439 2447 +8
========================================
+ Hits 69504 69567 +63
- Misses 86088 86136 +48
Partials 239 239
Flags with carried forward coverage won't be shown. Click here to find out more.
|
✅ Deploy Preview for determined-ui ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
just noticed warnings in case reviewer miss it. (im a non-reviewer :))
Screen.Recording.2024-04-24.at.2.12.06.PM.mov
@@ -51,16 +55,17 @@ export class UserFixture { | |||
username = safeName('test-user'), | |||
displayName, | |||
isAdmin, | |||
password = 'testPassword1', |
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.
Can we pull this from an env variable in circle CI? The playwright context should probably be the context for it. We should avoid hardcoding passwords in these tests so that they are environment agnostic.
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.
if it's required upon create, I'd suggest a new EditArgs
interface with the optional password
if (username !== undefined) { | ||
await this.userManagementPage.createUserModal.username.pwLocator.fill(username); | ||
} | ||
if (displayName !== undefined) { | ||
await this.userManagementPage.createUserModal.displayName.pwLocator.fill(displayName); | ||
} | ||
if (password !== undefined) { |
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 believe tests are failing because the UI doesn't allow blank passwords on edit. Is that OK? Do users need to update their password whenever they edit? That seems like it should only be required on creation to me.
If we are sure about this behavior then the edit test needs an update.
Line ref:
test('Edit user', async ({ page, user }) => { |
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.
No, I agree, the intent was that a blank password on the edit modal should mean "keep the password the same" and it shouldn't be required if the user exists already.
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 see why the e2 tests fail, but I think the app behavior is a bit odd there. Let me know your thoughts.
@@ -25,6 +25,10 @@ export class CreateUserModal extends Modal { | |||
parent: this.body, | |||
selector: '[data-testid="isRemote"] button', | |||
}); | |||
readonly password: BaseComponent = new BaseComponent({ |
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.
can you include the form area so we can get PASSWORD_RULES and check for those appearing properly? it could be in another PR if you want
… around remote users not needing passwords
a7e5385
to
4170c33
Compare
4170c33
to
b4493a0
Compare
6dc10d6
to
be61f75
Compare
Co-Authored-By: justin.comins@hpe.com
…ate-user-password-prompt
Co-Authored-By: justin.comins@hpe.com
All right, thanks to @JComins000 e2e tests are passing, and with his tests merged in there's pretty good coverage for what happens to a user after their password is set or changed with this new workflow as well. @djanicekpach would you mind taking another look when you have time? |
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.
good stuff! help me out with PRs to readme.md and password validation later :-)
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.
Password prompts work as expected 👍 Should we mention this in release notes?
Also want to mention that usually there are two inputs of passwords, something like
I don't feel too strongly about this, it's up to you and/or design.
One thing I noticed is when rabc enabled, the password field does not show up when remote is on and off, is this expected? Shouldn't we allow setting password when remote is off?
@gt2345 Thanks for the review!
Added.
I'd personally prefer to go without, since there's a visibility toggle on the field already; not sure who else I'd confirm design with here, but I'll double-check with my team.
Great catch, I missed parentheses over a group of conditions, but on another go through it, the rbac check was redundant anyway. Should be fixed now. Thanks! |
I'll add the password confirmation field shortly. |
c5fbd98
to
6004eb0
Compare
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.
Thanks for the fix.
I noticed that with rbac enabled, when editing modal opens for remote user, the password field would show up even though it shouldn't
It also seems like we can submit password change for remote user, and backend would throw an error.
- Using OSS, we can submit password changes for remote user. I'm not sure this would happen during production though.
- Using rbac, we can first change a remote user to non-remote user, then submitting password change would trigger the error. I think this maybe related to the backend.
@gt2345 looks like you caught another typo. df77cfc fixes it. Thank you! |
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.
Password prompts work as expected 👍
Ticket
DET-10221 feat: prompt for password when creating a user in web UI
Description
BREAKING CHANGE: adds a password field to the "add user" and "edit user" modals. The password is required when creating a new user; if left blank while editing an existing user, their password will remain unchanged.
Test Plan
The unit test for this modal has been updated to ensure a password is used and the form submits properly.
To test manually, log in as an admin, and ensure that an invalid password cannot be submitted when adding a new user, and a valid one can. With an SSO provider enabled, marking a created user as Remote should remove the password prompt and requirements.
Known issues:
Checklist
docs/release-notes/
.See Release Note for details.