We have moved to GitHub Issues
Created by Shannon Deminick 29 May 2017, 11:01:15 Updated by Claus Jensen 11 Jul 2017, 08:04:26
Subtask of: U4-8632
We already have this funtionality built into the change password dialog, there are a few 'rules' that govern how the UI works and what functionality the change password fields have.
We can use this same logic for the edit user page, the REST model will return what these rules are.
This can be tested in the user section, depending on the values configured for the membership provider, you can reset a password if that is enabled otherwise it will prompt you for an existing password
--This seems to work as intended.--
Actually no - reopening... there's some quirks:
enablePasswordReset option in
web.config doesn't really seem to have any effect on this. I tried having it set to both
false while recording the video here and it still allows me to reset (assuming this is not how it should work according to above?)
If the password field becomes dirty after clicking
Change password - the
Reset password option does not work. This is a problem if you are using a password manager as LastPass as it will autofill that field - and even after deleting the password and clicking save - I get the same error due to the field now being dirty.
I think this is happening because clientside validation will still take place (although the fields are hidden when selecting reset) .. so it will never actually submit anything to the server (nothing happens in the Chrome network tab). So there's also no exceptions happening here.
@claus this is by design, see this comment here: https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Core/Security/MembershipProviderExtensions.cs#L34
which is based on this http://issues.umbraco.org/issue/U4-7009 (the original commit for that is here https://github.com/umbraco/Umbraco-CMS/commit/b1c6276a67a37930112e390f32dbf2c62ea5c994)
So if you log in as a non admin you'll see it working the way you expect
I'm looking into the password field dirty thing tomorrow. In the meantime you can verify the above.
Makes much more sense then :) It's working perfectly with a non-admin user. Sorry about that!
Reopening for the dirty field part.
Ok, this was super annoying to fix but it's fixed now. I tried doing this all sorts of ways but our version of angular makes it super difficult to disable/remove/add validators at runtime from a controller and a directive won't work for this since the check box needs to control the validators for the other ngModel's. In angular 1.3 (IIRC) there's a $validators collection which makes this all much easier. I also tried creating custom validators which would work but then it's a horrible amount of extra code that isn't really reusable.
The end result was actually quite simple, we use ng-if instead of ng-show which will remove/reset the DOM elements and therefore the valdiators for the form.
FIxed in rev: 9462f8ad8580ee629c7b043014088a40eeaf8b83
Works perfectly now :) and yep - those validators are a pain to work with in our angular version...
Backwards Compatible: True
Due in version: 7.7.0
Sprint: Sprint 63
Story Points: 0