I’m trying to change the email address for a user in Dashboard via Formage. I’m unable to do so due to an LDAP constraint violation. Dashboard logs show:
[2015-04-13 11:49:11.841] [WARN] ldap - "uid=USERID,ou=users,dc=openmrs,dc=org" already has a pwdPolicySubentry attribute, which is not supposed to appear on users (!)
What is this pwdPolicySubentry attribute and how can I get rid of it?
Actually, that attribute is used for password reset, and it only exists when we want to perform a password reset. So something here is wrong, but it doesn’t really matter as it will be deleted once we have done. So you can ignore the warning. But you helped me to find a flaw in my sync logic with OpenLDAP, the password in OpenLDAP should be reset only if we changed it.
But as for the reason why you can’t change the email address, I really don’t know. It could be anything, as LDAP constraint violation will be throwed no matter what error happens for the sake of security 
I haven’t touched the LDAP either for a long time… and might be wrong on this. Maybe @elliott have some thoughts.
@plypy is there a quick fix? – PS see my thread on breaking the trees that are forked – my fault – I hope you don’t have any unmerged code there – if you don’t – just trash it and refork…if you do…I’ll help you merge… but it’s easier to just refork…I kind of painstakingly made the history clean 
and also added some stuff.
Only this line matters. It checks whether the password has been changed, however, it will always return false as we were comparing the hash with cleartext. We can change that to utils.checkSSHA(userobj[conf.user.password], pass).
Anyway, it’s just a performance issue.
Just had a few busy days
I’m wondering how did this problem go, is that solved? @michael
And had the password updating logic been fixed? @r0bby If you are not available, I’ll try to find time to get that fixed (so many classes…)
Problem is not yet solved. It is only the one user with the problem right now though, as far as I know!
@plypy will probably be able to fix it faster than I can…that said I can work on it – and backport the fix for immediate deployment…currently master isn’t in a deployment state (yet). Hoping to have it in a state before GSoC starts – at least for the UI improvements from GCI.
Well, I have to know more details to solve this. Maybe @michael could grant me ssh access?
@r0bby… Well then, let’s first leave this password-sync issue as it is.
If it was more than one user affected than i’d say – it’s critical…but one user isn’t critical…
Not sure if this is still a thing you’re working on, but since my final exams are done I’ll explain a bit:
pwdPolicySubentry overrides the global password policy for a single object. The dashboard changes changes a user’s password policy before it resets their password. During a password reset, the dashboard modifies that specific user’s policy, sets their new password, and then sets the user back to the global password policy (removing the pwdPolicySubentry attribute).
So if a user has a pwdPolicySubentry sitting around on their account, it’s likely that something broke during a password reset for that user. Not sure how this could have happened, but it may be something in @plypy’s user model, or in the ldap service layer, which was mostly written by me in 2012.
A safe fix would be editing this user’s ldap object and removing the pwdPolicySubentry attribute altogether.
At one point many years ago we had deployed a web UI for this. Is it still around? Are there any plans to include it in the dashboard deployment?
Somebody make a ticket and add the gsoc2015 and final labels – and give me add to this epic – it’s one of the backend improvements that needs to be made – we should make it easier to manage these things…
I would discourage allowing LDAP objects to be directly modified in the dashboard—you can break things really easily this way, and could goof up the sync between LDAP and MongoDB. Situations that require manual modification of the database are bugs, not features. (If you want to continue this discussion let’s move it to a new thread)
We used to have phpLdapAdmin installed on santa.openmrs.org but it’s not around anymore. I’d recommend using Apache Directory Studio to SSH into prod, connecting to LDAP using the LDAP superuser account, and modifying this user object that way.
If possible I would like to request the option to change an email address for openmrs id as I created it on an email I stopped using later and wanted to change it later but didn’t find an option. This though not a required feature is good to have for those few who want it:ok_hand:
@maurya Have you tried to do this on https://id.openmrs.org/? Regardless please open a help desk case for further assistance. Thanks!
I agree. What should happen is id dashboard should seamlessly backup changes to LDAP…eliminating the need to do this entirely…but having this at our disposal is good.