I have just imported our old fault tracking data into JIRA, and ended up with some usernames that I need to make unselectable as assignees (people who have left).
To do this, I removed them from the groups to which they were assigned.
However, there are 3 for which this does not work.
I found a possible solution in the KB here: https://confluence.atlassian.com/pages/viewpage.action?pageId=281480970, however this does not work - the users do not have multiple child-id's.
They all belong to a JIRA Delegated Authentication Directory - but then so did all of the other users that I was able to remove from the groups.
Can you please help me to resolve this?
make unselectable as assignees (people who have left).
you can mark them as inactive at first...they can't be assigned to issues then.
They all belong to a JIRA Delegated Authentication Directory - but then so did all of the other users that I was able to remove from the groups
i didn't get this...sorry. what exactly do you mean?
Can you confirm your jira version?
This is a known bug on jira 4.4.1 where in if you delete a user and then re-create the user with the same username then it is impossible to remove him from group membership. I presume that those three users were re-created and hence you have the problem.
The issue was fixed in jira version 4.4.2.
To replicate the issue use these steps.
It seems that there is no way to fix this issue. The upgrade will only prevent this issue from re-occuring but will not fix existing bugs.
Just checked on atlassian. This might resolve your issue.
1.Identify the problematic user_name
2.Run the following SQL query against JIRA database
SELECT ID,child_id,parent_name,child_name,directory_id FROM cwd_membership WHERE child_name='<problematic user_name>';
The query will list down all of the membership under the problematic user_name
3.From the result of the above steps, ensure there is a different child_id with the same directory_id before proceed to the next steps. If there are no multiple child_id, this is not the issue
4.Remove the problematic row(s) by executing this SQL query against JIRA database
DELETE FROM cwd_membership WHERE not exists (select * from cwd_user where id=child_id);
Please ensure that database backup is in place before proceeding all of the above steps
The above command would delete all rows relevant to the offending child_id value which comes from the undeleted rows
I guessed so.
This was fixed in JIRA 4.4.2 with https://jira.atlassian.com/browse/JRA-25611
The fix stops JIRA getting into a bad state, however it does not undo a bad state if an instance entered it before the fix was applied, so the workaround may still need to be performed for some customers.
There is a workaround given by Bjarni in this url. There is no guarantee but might just work for you. Take back-ups before trying it out.
If you want to try the database approach, you would be able to remove these users from 'jira-users' by using the below SQL query -
SQL> SELECT * FROM cwd_membership WHERE child_name = 'user_name';
//This will fetch mutliple rows for a user present in different groups.
//Find the CWD_MEMBERSHIP.ID value for row containing 'jira-users' value. SQL> DELETE FROM cwd_membership WHERE id = 16217; //ID=16127 belongs to the row for 'jira-users' group. SQL> COMMIT;
NOTE: Test this on your test JIRA instance by shutting down the JIRA DB and then restart and reindex after executing the above SQL query. Take and XML backup before applying it on our production JIRA.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs