Back Story:
We just recently switch from using Jira and Confluence OnDemand, to using the download versions.
When I imported the backups from the OnDemand instance into the download versions, the same set of users appeared in both the Confluence Internal Directory and Jira Internal Directory. This is not exactly what we want since we have a 50 user Confluence license and 25 user Jira License.
I have set up a Jira User Server and Confluence is using it, however, we need it to be second precedence to the Confluence Internal Directory so that when we add a Confluence user, they do not become Jira user, similarily when we create a new Jira user they will be able to access both Confluence and Jira.
What I set out to do was to delete the users that are in the Confluence Internal Directory who are already in the Jira User Server so that if a Jira/Confluence user changes their settings in Confluence, it will affect their Jira account and not the Confluence one, since we want the Confluence Internal Directory to be higher precedence.
Here's the problem:
I can't delete some of the users from the Confluence Internal Directory because they have authored pages, even though a user with the same name exists in the Jira User Server.
Disabling does not work because if I disable a user from the Confluence Directory, their account from Jira will not show up.
Is there some way that I could maybe manually delete these users from the Confluence Internal Directory while the User Directory precedence is still set to have the Jira Server as the default. Perhaps right from the database? Like if I were to delete them from dbo.cwd_user?
Hello Steven,
If you look at the license detail page specified below what is your user count?
https://confluence.atlassian.com/display/DOC/Viewing+and+Editing+License+Details
If they really are dulplicate users, I don't think they should run over your seat total. To clarify, are you able to upload a screen shot of what you are seeing? My best guess is that you are just seeing two possible direcotries (sources) from which your users can authenticate. So long as the user names are the same we should not duplicate seats.
Manual deletion of users is not supported or recommended. If you are seeing duplicate users you should be able to disable JIRA as an external user direcotry as described in the article below.
Please let me know if you have any further questions.
I mis-spoke when saying there are 'duplicate' users. They do not actually show up twice but they exist in both the Confluence Internal Directory and Jira Directory. Because we have a larger license for Confluence, we want that internal directory to be first presendence but at the moment if we do that, then the users that are common between jira and confluence are disconnected.
We want the users that are common between jira and confluence to be ONLY in the jira directory, then any extra confluence users will ONLY be in the confluence directory.
For example, my user: stevenr is suppose to be on both jira and confluence. I existed before the migration from OnDemand so I exist in both the Jira and Confluence internal directory. With Confluence using the Jira User server, I am in Confluence twice (but only show up once) depending on which directory has precendence. If the confluence internal directory was first (which we want), when I change my password, this change will not be reflected in jira because it modified the confluence internal directory.
This is the problem that we want to solve, by deleting all of the users that are common between jira and confluence from the confluence internal directory so that it will, instead, pull from the jira user server.
I tested deleting one user from the confluence internal directory directly from the database using these steps. (Can't remember exactly, was a little while ago. And this is of course after making a backup of the database.)
After that, now the user is authenticated by the jira user server instead of the confluence one, even though the confluence directory has presendence, which is what we want. I know this is a very unsafe way of doing this, but is there any other option?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.