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?
We resolved this in the end by editing the back end database with Atlassian's assistance, see JSP-147139.
Thank you for all your suggestions.
Hi Lesley,
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Lesley
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rahul,
Thank you - we tried this, but it did not fix it either. I have sent logs to the Atalssian support guys for them to have a look to see if they can suggest something. Otherwise I'll just have to mark them as 'do not use'.
Regards, Lesley
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
5.Restart JIRA
https://confluence.atlassian.com/pages/viewpage.action?pageId=281480970
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
https://jira.atlassian.com/browse/JRA-25647
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Rahul, We are running JIRA v4.4#649-r15830, which I thought was 4.4.2?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi lesley..
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?
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.
Ah - We have V4.4 and when I Edit a user I can only change the Full Name and e-mail address.
Presume this will be possible in 5.n... upgrade scheduled for next year so I'll make a note of this for then.
Thank you, Lesley
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
administration/users
select the user you want to deactivate....edit
remove the active flag there and you're done
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.