nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

All comments

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

LDAP server

Karie Kelly1

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?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

user