First, let me describe my situation.
First came Jira. Users were added to Jira's internal directory.
Next came OpenLDAP. The same set of users are represented within the LDAP dir.
After that came confluence. Confluence was set up to use the LDAP dir as its only user directory.
It is now desirable to have Jira use the LDAP dir in the same way that our confluence instance does.
I want to keep each user (their history comments, tickets, etc) but essentially "move" each one from the internal directory to the LDAP dir. I want associate each user's LDAP identity with their existing work in Jira.
How can I acheive this?
Thanks for your reply Marcus,
A look a the DB shows that issues are indeed related to users by user name. Fortunately all my LDAP users have the same user names as their equivalents in the internal directory.
I had enabled the LDAP directory along with the internal directory, but disabled it again as I had each user defined in both directories. This initial activation of the LDAP directory furnished the Jira DB with records for each user from the LDAP dir.
It should be noted that I have less than 10 users to modify so I did all this by hand. If one had a large number of users then a script could be built.
I'm using JIRA v5 by the way. Please note that my situation is reasonably simple: an internal dir with 8 users. Those same users represented in an openldap dir. internal usernames matching those found in the ldap dir.
Also, as mentioned above, user and group records from the ldap dir were present in the jira db due to my activating the ldap user dir in jira (and then disabling it).
So my circumstances may not be broadly applicable. Don't blindly follow this process.
What I've done to use the LDAP user records rather than those in the internal dir is as follows:
(1) Make a complete backup of the JIRA database.
(2) Shutdown JIRA
(3) Using pgadmin III (because my jira DB is in postgres & pgadmin is a convenient tool)...
(3a) Adjust table CWD_USER. Each user had 2 records in this table: one for the LDAP and the other for the internal dir. This table has a directory_id column that refers to the user directory in which the user is defined. For each user I recorded the id (primary key) of the row where the directory_id is 1 (the value identifying the internal directory) and I then deleted that row. In the remaining row I then changed the id to that of the row just deleted. This means that existing user attributes will still be associated with the user even though the user's directory has changed.
(3b) Adjust the CWD_GROUP table. Make all the jira groups have a directory_id matching that of the LDAP dir.
(3c) Adjust the CWD_GROUP_MEMBERSHIP table. For all the rows where directory_id == 1 (internal dir id), set the directory id to that of the LDAP user dir.
(4) If your LDAP user dir is disabled in JIRA you can enable it by changing the CWD_DIRECTORY table. Set the "active" column to 1 for the entry pertaining to your LDAP dir. You may also want to disable the internal dir by setting its "active" column value to 0.
(5) In my LDAP dir I created the following groups matching those groups already in use in jira, namely jira-users, jira-developers, and jira-administrators. Also in LDAP, I made sure that group membership matched what the jira db CWD_GROUP_MEMBERSHIP table showed.
(6) Restart JIRA. My users can now log in with their LDAP credentials. All their issues, boards, what-have-you is right where they left it.
Perhaps I won't need that backup. :-)
If your LDAP users already have the exact same username (case-sensitive) as they have on the internal directory, all their data should already be associated.
If they don't have the same usernames, you can merge the internal users into the LDAP users using one of the built-in scripts (Rename a User ID) of the Script Runner plugin. That script will remove the internal user and migrate all current issues to the ldap user.
Hope this helps,
Hi Marcus, while renaming the user I get the following error:
groovy.lang.MissingMethodException: No signature of method: com.atlassian.jira.issue.search.CachingSearchRequestStore.removeFromCache() is applicable for argument types: (java.lang.Long) values: 
I can't find the method removeFromCache() in the API for the class com.atlassian.jira.issue.search.CachingSearchRequestStore. This script worked for Jira 4.4.3. I was trying to make it work with Jira 6.6.3.
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events