Registration form issue

I have identified a bug in the functionality of of our registration form, which I feel fairly sure can be traced to a bug in CB.

In our form, conditionals determine that consecutive fields appear, as fields, above them, are filled in.

In addition, in the profile editor, the password field must only appear if a radio button ('[formatname], are you sure you want to change your password?') is checked. Therefore, there is a further condition that says that only if this radio button is checked does the password field appear in the editor.

For this particular condition, the 'Location' is set to only apply to the editor and not anywhere else. However, this does not work correctly.

The net effect is that, using the registration form, although everything appears to be correctly working, when a user fills in the password and its confirmation field, the password is not stored correctly, so that the user cannot log in, after logging out. They are told that email or password doesn't match. (BTW: first login, after registration confirmation, does work). N.B. If they use 'Forgot login' or change their password, in the editor it works correctly.

Therefore, I conclude that the 'Location' field is not applied absolutely correctly. This can be checked by registering in our site ( all4freedom.com ), logging out and attempting to log in, again. It fails. N.B. To remove the test account, later, one would need to use 'Forgot password', log in again and go to the 'Consent / Delete' tab. or ask me to delete it.

If I remove that condition, registration works fine, but, of course, the editor shows the fields, regardless of whether the '[formatname], are you sure you want to change your password?' field is checked or not.

Do not condition the password field. The same applies to username, email, and name fields. They are vital to user storage functionality. They may not condition correctly due to how they are accessed and checked against and are vital to user storage.

The location check is entirely based off the $reason supplied by the _getTabFieldsDb API calls, which fires onAfterFieldsFetch trigger and is what CB Conditional acts on. With that said it's probably a $reason value that CB Conditional isn't accounting for causing the issue (e.g. adminfulllist). Will add a check to ignore unknown $reason values. Beyond that there's nothing more I can suggest as it could be at some point CB is needing to check edit value for the field.