Password Portal: QER_PasswordWeb_Start differences 8.0.1 vs. 8.1 (passwordItem collection bug?)

In the password web portal, you normally choose between setting the central password (and use the password flow to implicitly set the password at all connected accounts) or setting the account (or Person.DialogUserPassword) password separately. Which method did you choose?

Hi Markus, 

Thanks for helping.

Depending on the user, I'm not even presented the option to set the centralpassword.

For my own user, I have the option to set the Central Password (interface in spanish):

For my test user , I dont have the option:

For another employee, I dont have the option either:

Weird. Just asking and trying to corner the bug, the employees where the central password is not displayed, are they

• Sub-identities or do they have a main identity assigned?
• Are the marked as outstanding or to be deleted?
• Are they marked as inactive?
• Are they locked out (Person.IsLockedOut=True or Person.IsLockedPwdAnswer=True)?

And, how did you authenticate against the Password Reset portal? 

Thanks again, Markus.

I thought the same about my test account , but the other one (ipp143) is correct and works perfectly.  So, all in all, these three accounts:

• They are not sub-identities. They are primary ones.
• No , not at all.
• They are active users.
• False on both attributes.

I always authenticate using the centralpassword and this one is transferred to the dialoguserpassword (system user password). In v8.0.1 I had a custom process, in v8.1 (thanks for the feature!!!) that transfer is carried out via the QER_Person_Publish_CentralPassword. The former custom process in v8.0.1 has been disabled. 

Now, I am confused. I thought the employee ipp143 is non-functional as well?

For clarification, you are using the Employee (role-based) authentication module in the QBMWebApplication entry for the password reset web portal?

The employee ipp143 is functional but he's not presented with the option to reset the centralpassword.

I've tried three users: 

• One test user. Not presented.
• Two active users mine and another employee. For my user it works. I am presented with the option. But the other one, it does not, same as the test user.

I'm trying to demonstrate that this behaviour seems to be random. 

Yes, employee (role based) is the auth module for both versions.

Honestly, we do not write code that decides randomly what to do :-) There must be a reason for the behavior but we just haven't found it yet.

I know that you did some customizing work as well. Are we talking about a plain OOTB password reset web or do you have any customizations in place?

Hehehe, good point. I didnt mean that you write code that decides ramdonly what to do. It's a way of saying "I do not know why it happens to some users and others doesn't". Apologies for that.

Yes I've done some customizations. In fact I replaced the module QER_PasswordWeb_Start for one of my own. In v8.0.1 it works fine, in v8.1 does not.

But as I said, all customizations have been removed.  This OOTB code upgraded from v8.0.1 to v8.1 .

The fact that it happens to some users makes me think that the problem lies on the person object layer rather than the web code.

Thanks again, Markus.

Can you provide a debug log from the password web, for the user where it doesn't show the radio button for the central password reset? I do have suspicions but want to back it with the log.

Sure.

In the mean time, I've called one of my customers , asked her to change the password and it worked. Took her to the v8.1 page and , again, showed no central password button. 

Let me know if the following link works for both sql and log files.

https://drive.google.com/drive/folders/1AHl03klaeCmmP_nZE5_rGb6acNR8Jsja

Thanks!