I am having a problem with a validation interaction that I had developed and I’m at a loss on how to troubleshoot it and hoping the community can help. The individual interactions all work, but when you try and do them one after the other they stop working. I used Key Up so that each key stroke is validated. The only one that is consistent in validating is Symbol, lower case, upper case and numbers only work if they are the first character. When I review the console after the first key stroke the next validation says “No condition met”. Can someone please review my file and give me some insight on what is happening?
Good password validation can be difficult. You’ve got a good start here, but some of your conditional logic is flawed and obviously doesn’t work the way you think it does.
I’m not sure why you have some validation done on Lost Focus and others on Key Up …for example, I would want to know as soon as possible that I’ve entered at least 12 characters, and not only after I click somewhere else. But, if you have certain validation rules or requirements, you can do it this way …just not the best usability.
I’m not sure why you have additional logic conditions in some of your cases, like “and text on this is alpha”. What purpose are you trying to achieve here? Because you have a validation constraint of including both alpha chars and numeric chars, this doesn’t make sense. As soon as a user enters any digit, special char, or any other non-alpha char this would equate to false, and that is not what you want.
You have set some rules to show when password requirements are met, but not when they are lacking. So, if a user enters a digit, the “Must include at least one number” requirement can go green, but if they later delete that number (like backspace over it) that requirement should go red. (…And your logic in the “numeric” case, If text on This is numeric, tests if the text contains only numeric chars, so as soon as it contains a non-numeric char it would equate to false. Also, it is not obvious, but a space char is considered “numeric” so if a user presses the spacebar key then “is numeric” equates to true. Most password schemes don’t allow for spaces, and even if they do, it wouldn’t be considered a number.)
See this post for an example of how you can test for validation conditions and change individual constraint messages (e.g., show green check for "met" or red X for "not met" conditions.)
I’ve applied this logic to your code in this updated .rp file. See the “Login (1)” page. password-validation.rp (883.4 KB)
At a high level, the Key Up event on +new tests its text value against each individual requirement in a series of “If—Else If” conditions, changing it to green when met and red when not met. For example, the first set of two conditions test for a length of at least 12 chars:
The post I linked to above goes into logic details for most of the conditional cases.
I disabled the new and confirm password fields by default. The new password field is enabled when the current password is filled out. Ideally, you’d have an existing password to test against, but for now it accepts anything more than 3 characters (let’s say old passwords could have been 4+ chars) …of course, change this as you need. When all requirements are met for the new password, the confirm password field is enabled (see details below.)
Your algorithm to increment the "N requirements met" counter uses a global variable, "Met", but you never increment the variable, you only increment the text value of the counter, so it always equates to 1. So, you should either increment the global variable first, ([[Met + 1]] and then set the value of the counter to the variable, (Set Text +met-requirements to value of [[Met]]) or just increment the counter directly without needing a global variable. I did the latter in the file above.
I moved the counter increments to the constraints dynamic panels, so any time they change state they handle the resulting counter change (so changing from red to green increments the counter; green to red decrements the counter.) This method is more reliable for ensuring the count is correct. Also, any time an individual requirement is met/unmet–triggering it to change state–it fires the Rotated event of +requirements. I’m using this event as a “listener” or “handler” –a kind of built-in sub-routine that changes its state to “met” or “not-met” depending on how many requirements have been met. Then, whenever it changes to “met” the confirm password field is enabled (and counter values set to match.) Note that I made these changes first only on the +length requirement, tested that it worked correctly, then copied the whole Panel State Changed event and pasted to each of the other requirement panels.
(Because you really have just one counter and one description, you could save some overhead by styling this once, instead of creating a dynamic panel with 2 states and duplicates of everything. You could set a “selected” interaction state that has green text, then set it to “selected” when all requirements are met. Or, you could use “rich text” to set the color.)
I added a Panel State Changed event to +requirements so that when it changes (especially from not-met to met) the "green counter" in the "not-met" state matches "+met-requirements" red counter. Also, when all requirements are met it enables the +confirm text field.
I moved the "Enable +ok" action and condition to the Key Up event of the +confirm text field, and added tests for matching text values as well as all conditions met.
There are further considerations you may need to take into account, depending on needed specificity, like handling invalid characters (e.g., most passwords can’t have spaces or commonly used logic symbols, like ‘&’ or escape sequences, like ‘/{’ ). You can work with your client, dev and/or quality partners on details.
If you want to include functionality for the "view" eye icon in a password field, to show masking chars (like bullets or asterisks) by default and actual chars when "view" is on, then you can make a dynamic panel from the existing password field, name the state something like, "hidden", duplicate the state and name that something like, "shown", go back to "hidden" state, right-click the text field and select "Input Type : Password". Then add a Panel State Changed event that copies the text value of the text field in the current state to the text field in the new state. Do the same for the +confirm text field.
I appreciate your feedback on my issue and I will rework the interactions. I don’t pretend to be the most efficient at designing the interactions so your feedback is very helpful. I had hoped when I made this post that it would be you that would respond. Thank you very much, I’ll let you know how it goes.
