Jira INACTIVE user READ only

[KP11]

We have a USERID that is READ only INACTIVE. Users are still assigning issues to the userid because of the same name different userid/email. In the assignee pulldown the email shows not the userid. Is there a way to delete the secondary account from the pulldown?

Pulldown Example email : JohnSmith - JSmith@acme.com userid jsmith

JohnsSmith - JohnS@acme.com userid smithj

When a user assigns a issue both emails show up. It was the same user. One userid has option to EDIT the other is read only. How do we clear it from pulldowns?

You cannot remove user from group The user's directory is read only.

[Nic Brough -Adaptavist-]

There's no such thing as a "secondary account". They are two separate accounts in Jira.

You need to check both to see why they are "assignable" in the project, by looking at the "permission scheme", and update them so that they are not (that removes them from the "assignee" list)

Similarly for the edit permissions - that's defined there too.

Edit - Apologies, I should have added: https://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions

[KP11]

USERID not in the group assigned to that project. Permissions scheme

The obsolete groups they are in cannot be changed because its READ ONLY.

Is this LDAP issue? Do we need to remove from LDAP?

One is in LDAP only

JIRA Internal Directory

Groups Project Roles Edit Delete LDAP server Groups Project Roles

[Karie Kelly]

Why would inactive users ever be shown in any user select field vs being shown if they were already selected, for historical purposes? That is the reason for having inactive or disable functionality and how many other apps work.

[Nic Brough -Adaptavist-]

Well, yes, you need them shown for historical reasons, and if they're still assigned an issue, that doesn't necessarily change just because they've left. Also, it could still be perfectly valid to assign issues to inactive users. One obvious business process is to assign "resolved" issues back to the reporter on resolving them or closing them to indicate who's responsible for them now. Even though they are closed, they still belong to the person who raised them, and even if they've left, you still want to report on things like their re-opening rate.

Anyay, your previous posting, two things:

1) Obsolete groups read-only? You don't do that in Jira, but if you've got obsolete groups in LDAP, then you should be removing their usage in all your permission schemes and project roles to make sure they aren't used by accident.

2) I have no idea what's happening from your posting. What does your permission scheme say on the line "assignable user: can be assigned issues"? (Do NOT confuse that with "assign issues: can assign issues to people"). Then, can you tell us what groups and roles both users are in?

[KP11]

1. Duplicate userid for same user. We cant get rid of the obsolete one.

2. Under Assignable:Group (jira-developers) Project Role (Users)

We are looking at ACTIVE users there are over 200

[Nic Brough -Adaptavist-]

Right, so remove the users from the group jira-developers and the role of users in that project and you're done.

[KP11]

Which brings us back to the USER LIST greater than 200. Can't scroll past 200. The LIMIT was only searching. No affect on list wuthin a field

[Nic Brough -Adaptavist-]

I've not seen any limit on user lists (I didn't mention that before because I didn't recognise it), and so I'm not sure where you think this limit is.

Anyway, whereever you're seeing it, you can simply go around it. Instead of looking at the project, just go to the user. You can edit a user's profile, get their list of roles and remove them from the roles there.

[KP11]

If we go by USER level the 1 profile is READ ONLY and we cannot edit list of roles

[Nic Brough -Adaptavist-]

Then there is something very odd going on in your setup - I don't know where your "limit of 200" is coming from, and you should always be able to edit user roles.