[CONFSERVER-28888] Unlicensed users (no application access or groups) still show in people directory in Confluence OnDemand Created: 11/Apr/2013  Updated: 02/Apr/2017  Resolved: 22/Oct/2015

Status: Resolved
Project: Confluence Server
Component/s: None
Fix Version/s: 5.9.1

Type: Suggestion
Reporter: Nick Mason Assignee: Richard Atkins
Resolution: Fixed Votes: 33
Labels: affects-cloud, affects-server, ondemand, people-network-groups
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is duplicated by CONFCLOUD-53845 New created JIRA Users are showing in... Resolved
is duplicated by CONFSERVER-34341 People Directory shows users that doe... Resolved
is incorporated by CONFSERVER-19116 Only show users with "can use" permis... Resolved
relates to CONFCLOUD-28888 Unlicensed users (no application acce... Resolved
relates to ID-76 Ability to deactivate/activate users Resolved
is related to CONFSERVER-16477 Provide the ability to filter out dea... Resolved
is related to CONFSERVER-19116 Only show users with "can use" permis... Resolved
Feedback Policy:
We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see An updated workflow for server feature suggestions.
Last Touched By: Rachel Lin
Last commented: 2 years, 22 weeks, 1 day ago


NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

CONF-16477 set the default for the people directory (and other things) to have deactivated users hidden. There's no concept of "disabled" users in OnDemand, our equivalent is users having no application access and not being a member of any groups.

Unfortunately this means that users that are "inactive" in OnDemand still show in the People Directory as they're not explicitly using Confluence's "Disabled" flag. Confluence should treat users who aren't in groups and have no application access in the same fashion as disabled users.

Comment by Bill Latham [ 10/Feb/2014 ]

Not to get into semantics but this really is more than an improvement – this is a pretty severe issue for OnDemand users that seriously undermines faith in the security model (deactivated users certainly do not look deactivated when they appear in the People Directory).

Comment by Glenn Burnside [ 14/May/2014 ]

This is really frustrating and provides a poor user experience, as we have all these former employees in the people directory, and I can't delete them or make them not show up. Can't we get a fix for this?

Comment by Patrick White [ 02/Jun/2014 ]

Agreed with above. The fact that "inactive" users don't behave like "deactivated" users is very lame. As a user, I NEVER want to see a deactivated user. I don't want to be able to share pages with them, or mention them in a page. Same goes with JIRA. This has annoyed me so many times!

Comment by David Comdico [ 23/Jun/2014 ]

I'm very disheartened to see how Atlasssian is addressing this bug.

We have a Confluence-only OnDemand instance and are experiencing this problem-despite the claim above. Before the recent upgrade we were able to disable users from the directory with no issue. The recent upgrade is causing the bug and it would seem that Atlasssian made a gross miscalculation in understanding the requirement in the recent user management transition. This needs to be fixed. I can't imagine how anyone would find this acceptable.

Comment by Caroline King [ 24/Jun/2014 ]

I too am finding it very frustrating that I am unable to easily disable users (we also have Confluence-only OnDemand). Prior to the recent upgrade I was easily able to disable someone with the tick of a box. I now have to remove them from groups and field questions as to why they still appear as active in the People Directory when they have in fact left the company

Comment by Jan Sroka [ 07/Oct/2014 ]

Considering that this appears to be very basic functionality of enterprise software, how come this is not fixed yet? In what version and more important when will a version be released that fixes this issues?

Comment by Colleen Coleman [ 14/Oct/2014 ]

We are still experiencing this issue. We use the people directory as our employee directory and having former staff appear is not only confusing to new employees but sloppy. This needs to be resolved ASAP. Can you at least provide a viable work around until a permanent bug fix is in place?

Comment by Caroline King [ 14/Oct/2014 ]

This issue is nearing 9 months without an acceptable resolution. It is confusing and very unprofessional to have people that have left our organisation appear in our People Directory or have Personal Spaces showing. I am having to go in and write (Former Employee) and that is even worse from a HR perspective. Please can you look at this issue as a matter of urgency - 9 months is an unacceptable time to have to wait.

Comment by Robert Roskam [ 22/Oct/2014 ]

I realize that this is more of an annoyance than a horrible issue, but as time goes on and more users cycle through our system and become deactivated, this will dramatically increase confusion and our internal help desk will have to bear the brunt of the questions.

Comment by Kit Crawford [ 29/Oct/2014 ]

We are migrating from self-hosted Confluence to OnDemand Confluence. I was told that if any user had ever edited a page in Confluence they can never be removed from the user base, in order to preserve editing history. Annoying, but at least I could disable the ex-employee users, and they were only known to me as an admin. I was extremely annoyed to find that disabled, ex-employee users that did NOT show up in the People section of the self-hosted Confluence, DO show up in the People section for the OnDemand Confluence. This is going to confuse and annoy the heck out of our current employees. Who are all these people? Why must I wade through them to find current users? Some of the ex-employees have not worked here for over 5 years and now they are coming back like ghosts. Why does the self-hosted Confluence now show these ex-users, but the OnDemand breaks this?

I cannot believe that this is a complicated issue to fix. How hard is it to not show users who do not have access to the application and are in no Groups in the People directory? Please fix ASAP!!

Comment by Colleen Coleman [ 03/Nov/2014 ]

Is anyone at Atlassian even looking at this issue? Can this be assigned to someone at Atlassian to resolve. As a work around I tried adding zz to the names of the deactivated users but this does not even sort them former employees to the end of the directory. Can someone provide any assistance?

Comment by Peter Lewis-Dale [ 08/Dec/2014 ]

We have a buisness where we have a lot of contract staff, project partners come and go and having all staff that have ever been in the system appear on the staff list without being able to filter is really not good for a product which is amied at being a corporate wiki. Frankly it's a little difficult having to explain this.
Even at the higest level you already have a flag for application access to confluence under user management, a simple fix to impliment on the user interface!

Comment by Kit Crawford [ 08/Dec/2014 ]

Over a year and a half and they have not even assigned the issue to anyone. This is maddeningly annoying, especially because it seems like such an easy fix. There must be a flag for users not in any groups - how hard can it be to not display those users in the People Directory? This is a seriously problematic issue for many customers - especially if there are HR issues where it's really bad for people to see a list of past employees as though they are active users of a company intranet that has sensitive data.

This ticket seems to be an echo chamber for people complaining about the issue. Hello Atlassian? Care to comment on why this issue is not moving ahead with a fix?

Comment by Jeremy Stagg [ 08/Dec/2014 ]

Substantial interruption to the security and community effect in the business where I work. The issue is compounded with OnDemand service sending out pages to read in Confluence from users who are set to inactive as they cannot be deleted / removed.
As the delays are long term from Atlassian then the end result is a push away from the service.
We are looking to transition out of the product as a result. It's not fit for purpose.

Comment by John Parsons [ 06/Jan/2015 ]

Just curious why this is listed as an improvement, and if it were a bug, would it get bumped up a little in priority?

There's a note on Atlassian's wiki (https://confluence.atlassian.com/display/Cloud/Searching+the+People+Directory ) that states:

" By default, deactivated users (disabled user accounts) are excluded from the people directory. You can include them by adding the showDeactivatedUsers parameter to the URL..."

If I'm understanding this correctly, these users should not be showing up, so this is really a bug, not an improvement, correct?

Comment by Richard Atkins [ 08/Jan/2015 ]

Hi John Parsons For some background here:

There are 4 states a user account can be in:

  1. active and licensed,
  2. active but unlicensed,
  3. disabled - doesn't matter if they're licensed or not
  4. deleted upstream - doesn't matter if they're licensed or not. Note that Confluence can only get in this state if it is configured with a remote User Directory such as Crowd, JIRA, LDAP or Active Directory.

The people directory (and mentions and various other user autocomplete dropdowns) is filtering away users in states 3 and 4, but not the users in state 2 - active but unlicensed. This issue is caused by us not having implemented https://jira.atlassian.com/browse/CONF-19116 , as well as us not yet supporting deactivating user accounts directly in Ondemand (the administration interface had various limitations preventing us from providing the feature until quite recently).

Would this issue get more priority if it were a bug? No. Our bugfixes follow the priorities set forth in https://confluence.atlassian.com/display/DOC/Bug+Fixing+Policy and since this is not a critical issue, it's not going to get the attention of the bugfix team in the near future.

But don't lose heart. We will be rolling out support for deactivating user accounts in OnDemand very soon. And because it annoys me just as much as it must annoy you, I'm working on fixing the improvement in CONF-19116 anyway, so you won't have to go through and manually update all your unlicensed user accounts to deactivate them too.

Comment by John Parsons [ 09/Jan/2015 ]

Thanks Richard, is the ticket for deactivating users: https://jira.atlassian.com/browse/ID-76? And does this mean all users in Cloud instances are active, regardless of what application access and groups they're part of?

Comment by Richard Atkins [ 09/Jan/2015 ]

John Parsons that's the correct issue, and you're correct about the user states too. Once CONF-19116 is implemented, there won't be so much difference between the two states in Confluence.

Comment by Leila Pearson [ 10/Jun/2015 ]

We are also seeing lots of users who have never logged into Confluence and do not have access to Confluence and never have had that access. We did originally set up our Confluence site to use JIRA for user management - but these users (a lot of them are administrative accounts or other special accounts in Active Directory) never had access to JIRA or Confluence.

The people directory is very confusing to look at since it shows all of these non-people users along-side real people - and also actual people (some external contractors for example) who don't have access and should not be listed there.

Any updates on a fix for this?

If you can filter out "active but unlicensed" that would solve the issue for us.

Comment by Richard Atkins [ 22/Oct/2015 ]

This has been fixed as part of implementing CONF-19116, to filter away all users who do not have a Confluence license from the people directory (and related parts of the Confluence UI), rather than just deactivated users. This fix was deployed in August 2015.

Generated at Fri Mar 23 20:35:55 UTC 2018 using JIRA 7.8.0-m0003#78000-sha1:e5ec29087cffe574ad41394afe143eb1de3ecdfb.