Hi,

I've found a little workaround for this problem. It seems that when you de-activate a user, she still gets a password set ; in the same time, the Personal Directory lists all users with a password set. So, you may unset the password for the deactivated users and they won't appear anymore in the Personal Directory. EDIT : it also deactivates the ability to mention these deactivated users.

I didn't find any way to unset a password through the web interface, which means that eventually you have to manually update your database...

If you use a SQL DB, this request will do the job :
update cwd_user set credential = "nopass" where active = "F";
(cwd_user is the users table, credential is "X" if a password is set or "nopass" else, and active is "T" or "F" regarding the user is active or not)

Cheers

Hi is there a fix for this yet? We are encountering it in JIRA 6.4.4 using a Crowd backend, with users that have been individually disabled. We are getting complaints from our users about it. Duplicate users appear in the @ and ~ lists to link users to cases.

I'understand. You service desk agent led me to this issue.

To be clear: tomasz.belina2 I take it in your environment it's not the individual users that are disabled, but a whole remote user directory. This issue addressed deactivating individual users in an enabled remote user directory.

In the case of deactivating an entire directory, there's nothing listening for the underlying DirectoryUpdatedEvent to reindex all the affected users, so they are left as if they're enabled, cluttering the UI in the people directory and mention autocomplete. Similarly, we currently fail to reindex the users affected when reordering user directories (https://jira.atlassian.com/browse/CONF-36277), which can mean that we fail to detect when a user's full name, email address or other user attribute change due to user shadowing. We'll have to address both of these use cases when resolving that issue.

In my case it is very simple. I've notice this problem in version 5.6.5 and according to advice I got from Atlassian Service Desk (https://support.atlassian.com/servicedesk/customer/portal/14/CSP-148446) problem should be solved in version 5.8.4. So I've migrated confluence to this version and problem still exists.
I've made a site export and it looks like there is no "InternalUser" object for users from disabled directory.

Hi niebieski,

Could you share with us the steps to reproduce that you did for 5.8.4?

Thanks,
Minh Tran
Confluence BugMaster

On confluence 5.8.4 issue still exists.

We got the same issue here. The workaround with enabling and disabling is no alternative for we have to many users to manage.

james.dellow This should already be in Cloud, as it was fixed as part of a previous issue. Note that this is for inactive (deactivated) users only. For active users that have Confluence access revoked check https://jira.atlassian.com/browse/CONF-19116

Will this also be rolled out to Confluence Cloud?