I just upgraded from Jira Service Management 8.20.2 to 8.20.8 and noticed that when assigning a ticket to an agent, the agent drop-down list shows a duplicate of each agent. Does anyone know why this is and how I can fix it?
Check and make sure that you do not have duplicate users in your user directory. I am assuming you will not. If there are not duplicates in the user directory you should perform a full index https://confluence.atlassian.com/adminjiraserver/search-indexing-938847710.html#:~:text=Access%20Jira%20on%20the%20node,%2C%20run%20Full%20re%2Dindex.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would do a full reindex and not background. My guess is that the index is corrupt. A full reindex should fix it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brant Schroeder, so we actually do have duplicate user health check error. We sync user groups from AD and they automatically get added to the agents group/licensed. We also have a AD connection that syncs all of our domain users. We had no issues with this before the upgrade though. Not sure if its related to corrupted index or what but I'm not going to be able to do a full index until the weekend.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ok duplicate users is different and has nothing to do with the index. Are the duplicate users in the same directory? Or is one of the duplicate accounts in jira crowd directory and the other in the AD directory?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
They are in both directories, the "agent" one is being sync'd due to them being part of a group that is set to auto add them as an agent. The other is just syncing the entire AD user/local groups.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I saw this as a workaround but I've never connected to the database before so not sure how to do this?
As outlined in the BUG https://jira.atlassian.com/browse/JRASERVER-68456 , the workaround in this case is to Avoid using duplicate usernames across different user directories, or manually deactivate one of the user in the database (set active=0) (DB: cwd_user.active). Example:
update cwd_user set active = 0 where id = 10000
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jh Do you have a test instance of your environment where you can run scripts and test the changes before doing it in Production?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jh Do you have a way to snapshot your environment before making changes to the DB so you can roll back? Disabling the duplicate accounts should fix the issue and I don't believe you will have any other side affects. If you have a way to rollback I would suggest going down that route. If you do not have a way to backup I would suggest submitting a support issue to Atlassian with a support zip. The support zip will provide them additional information so they can ensure that this is the proper fix. https://support.atlassian.com/contact/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brant Schroederyes, it is a VM so I can take a snapshot before the changes. I've never connected or executed commands to the DB before, can you provide more information on how to do so?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jh To make changes in the DB you will need to first shutdown Jira. Once the Jira instance has been turned off you can then run your SQL scripts. You will need to identify the username and the directory that the user is associated that you need to deactivate.
You usually run the DB script when you have lots of duplicate users. How many users do you have? If it is only a small amount you can deactivate them in the user management section of the application. I would suggest doing this first to make sure it fixes the issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brant Schroederif the users are being sync'd from AD directory, the only way to disable them is via AD, I don't see a way to deactivate them from user management. I have about 240 agents but not all of them show as duplicates in the drop-down.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Jh are they a duplicate in the same directory?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brant SchroederYes, I have 2 directories that sync from AD. One of them is set to have User Object Filter to sync users that are part of a security group for Jira agents and the other one is syncing all domain users/local groups. Jira is identifying the users that are part of the agent security group are duplicates of the users in the all domain users syncing directory then I believe.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
OK that makes more sense. I would adjust how you are managing your users. Having two directory's that are syncing from the same AD environment is going to cause issues. also the fix above will not work. When you sync users are you bringing over AD groups? Do you have a group that identifies your agents in AD?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Brant Schroeder, yes I am syncing local groups as well and yes, there is a security group in AD that identifies the agents in AD. I tested this out by assigning an agent license to a user that is not part of the security group in AD and it does not show a duplicate account in the drop-down but right after I added the user to the security group in AD, it shows as duplicate.
I'm looking at my Application Access page and I have Jira Service Management access provisioned for 2 local AD distribution groups. I believe this, combined with the directory sync that is filtering another local AD group is the cause of this issue since there is overlap of application access being provisioned. If a user is a member of local AD group 1, lets call it "Jira agents" AND one of the two local ad groups that are set for Jira Service Management access in Application access then there will be a duplicate. Hope this all makes sense.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.