Just for clarification:
when I disable a user, do I still have to remove him from group "jira-users"?
Or is this now not necessary anymore?

@Hans
Sorry for the late reply.

How would I go about getting the disable user functionality when that is my workflow?

Sounds like you will need to wait for JRA-24937

Enabling and disabling by REST would be sweet, but I know the REST focus isn't really on admin yet.

I use crowd with JIRA, and the way I add users to jira is by adding them to an LDAP group. When an employee leaves, I remove them from all LDAP groups and then move them to a special OU, and they disappear from crowd (and JIRA).

How would I go about getting the disable user functionality when that is my workflow?

Perfect! Thanks!

Can you describe the process of getting users made active or inactive?

The Edit user UI will have an "Active" checkbox.
Users coming from Crowd will read the value from the Crowd server.

Is it done only through LDAP attributes? Or will the internal directory have the capability as well?

It will work on the internal directory, "Internal with LDAP auth", and Crowd Directories.
IF you have read/write access to an LDAP directory, the checkbox will not be shown on the UI as we have no way to "write" this back to the LDAP server, and we are still considering designs for JRA-24937.

Will the Crowd API or one of the JIRA API's allow programmatic query and set of the attribute for the internal directory

Yes.
The crowd User interface has an "active" flag - see User.isActive()
You will be able to build a User with ImmutableUser.Builder and set the active flag as desired, then pass this User object to UserService.updateUser() or UserManager.updateUser()
(Indeed the API and backend storage exists in JIRA v4.3 - however JIRA will ignore the flag for the most part, the only effect would be inability to log in).

It sounds good. Can you describe the process of getting users made active or inactive? Is it done only through LDAP attributes? Or will the internal directory have the capability as well? Will the Crowd API or one of the JIRA API's allow programmatic query and set of the attribute for the internal directory - perhaps similar to how Confluence works?

Good stuff .

Heads Up:

I have been working on this using 20% time, and have what I believe is a minimum feature set.
Unfortunately this was too late for v5.0, but you can test this out in a month or two when we start to release 5.1 EAPs.

The features I have are:

• Inactive users can't log in
• Inactive users don't count toward license limit
• Inactive users don't receive email notifications
• You cannot assign issues to inactive users
  However, you can edit an issue and leave the existing assignee even if inactive.
• Project Leads and Component Leads cannot be deactivated
• Inactive Users are displayed in UI, but with a trailing "(Inactive)" as an indicator.
• JQL searches on inactive users work (eg reporter=jdoe)
• JIRA will respect the active flag from Crowd servers
• JIRA does not have an active flag for LDAP users
  Because only AD has this concept AFAIK, and we are leaving the door open for JRA-24937

Disabled users should not show up on user selection lists either or at least have some indication they are disabled.

What's interesting - the feature is implemented in Confluence but not in JIRA.
Is it a problem to share knowledge between dev teams?

Is there really no intention to implement this or solve https://jira.atlassian.com/browse/JRA-2220 ? We really miss that must have feature as our instance gets bigger and bigger. Removing jira-user permission is not enough!

http://forums.atlassian.com/thread.jspa?messageID=257279089

It's disappointing to see the lack of attention on this six-year-old issue. This is a pretty standard requirement for any medium-to-large deployment, where users come and go.

Users can be removed from all groups to remove access, but they'll still appear in search results for User Picker fields, which practically ensures data integrity problems and "lost" issues, as "old" users will inevitably be picked.

We use a AD delegated directory so the Crowd directory has all the users we want even if they are removed from AD. It means we now have to manage users/groups in Crowd. But we still can't disable them in Crowd or JIRA doesn't see them .

We do have Crowd integrated with our AD, however, one can not delete the user in AD (or bad things will happen in JIRA), you still need to have the user exist in your AD. I don't want to have ex-employee's accounts lying around in AD for eternity.

We're not going to buy Crowd. We expect this functionality to be supported within JIRA itself.

Same here. No plan to buy Crowd.

JIRA is going to be integrated much closer with Crowd, perhaps we could take advantage of its deactivating functionality.

Who bought Crowd yes, will take advantage. Others like us, won't.
So advertising other Atlassian products here, does not help...
So far buying Crowd is not in our plans.

Since in the nearby future JIRA is going to be integrated much closer with Crowd, perhaps we could take advantage of its deactivating functionality.

http://confluence.atlassian.com/display/CROWD/Deleting+or+Deactivating+a+User

feedback on behalf of our customer

I think some work needs to done on Jira to make things easier for an admin to deal with this new licensing schema. I mean we have to deal with these user quotas, but have to do to many steps to simply deactivate them.

This is probably one of my top three gripes with Jira. When you've had a user base that has shrunk dramatically (that's just about everyone these days) this becomes a bigger annoyance.

Ideally, the names could go into a different table so that they still show up as reporters, etc but can be totally removed from the list of users.

However, what Anton mentioned on 21/Aug/09 12:30 AM was not documented. I had gone through Bugzilla import and internal team structure changes. I had to change the work flow to allow update of closed issues, and took over the issues assigned or reported by departed users; thus losing their history. Had I known about the above feature, it would have made things alot easier.

Hi Geoff,

In JIRA Hosted and in JIRA Studio you are only charged for users who have the Global JIRA Users Permission, i.e. permission to log into JIRA. This is what Matt Doar is referring to.

So there is a way to have an account that cannot be used, but exists for history reasons and does not count towards the charge total.

Please create an support case in our support system in the Enterprise Hosting Support or JIRA Studio Support depending on which one you are using.

Our Support Team will help.

Cheers,
Anton

Geoff,

Good point. If the charge was per user in jira-users then it would be ok, since deactivated users shouldn't be in any JIRA groups. You could try suggesting that to your hosting service.

~Matt

Good to know. I'll make sure I will never switch to that kind of service.

I'm moving to hosted JIRA where we get charged on a per-user basis. That means that I have 2 choices. Pay for users that have left the company, or lose their history.

Not fantastic.

I am able to assign issues to users who are disabled, and even assign them as Project Leads. I'm using the standard assignee field.

This is definitely needed also for us.

The actual work around (deactivating the user - no jira-user group) is good but not enough.
Just deleting the groups membership does not present to see the user in a pick up field

A proper "deactivate user" implementation is really needed.

This is an important feature for us. In effect a disabled user is like a user that has been removed/deleted from JIRA, except that the user still shows in the history of all issues. We actualy call it retiring a user, which probably a better description of what is needed. To summarise from all of what's been said above:

• Retired users cannot log in, be assigned issues, receive notifications, subscriptions etc....
• Emails sent to the JIRA system from the retired user will not be processed by any JIRA services
• Filter options for the "User Browser" for "All Users", "Active Users", "Retired Users"
• The option to enable a retired user at some later time
• Most importantly, the history of a retired user must still be visible in the history of all issues
• A retired user must not show up in any Browse Users Select List
• A retired user must not count in the license

Just started to get mails from postmaster along the line sof 'this user cannot be reached'. So every person that leaves my co is going to start generating SPAM for me? niiice! hardy perfect, but I can see a way to catch the 'rebound' and filter that against disabled users (well, for LDAP at least...)

This is definitely needed

Here is what I just did and is as of now our "disabling process"

1. Change user password
2. Remove user from all groups
3. Change user's email address to an address we set up to accept mail but delete all incoming mail automatically in the exchange server. JIRA allows for multiple users to be registered with the same email address. That way all the mail goes in that dump address.

A feature that would disable users would be much more convenient, however.

Matt - well, we disabled the Assignee field in our JIRA and use a custom field. The disabed user is still in the selection for this custom field. He also appears in the Reporter dropdown list (which is a JIRA field).

Thanks

User not in any groups still showing up as assignable? That would be a bug,
contact support

On Thu, Feb 21, 2008 at 5:42 AM, Doods Perea (JIRA) <jira@atlassian.com>

I agree with Doods. and David...

especially when users/contractors get disabled (e.g. they left the company) they should not be counted in the license check

Any news on this issue? The above issues (summarized by David Armstrong in his Nov 29, '06 comments) are legitimate JIRA issues that need to be addressed.

Further to that, we have JIRA version 3.12.1 running in one of our lab servers. After disabling the user (by removing him from all groups):

1. He still shows up in the Browse Users Select List (meaning he still can be assigned to an issue)
2. He still counts in the license (I know in Confluence a disabled user won't count in the license)

Thanks.

I would like the ability to disable certain users from being assigned/reassigned issues

That's simple to do. Make sure your permission schemes do not have any assignable users permissions
set to either jira-users group or a single user. Then, make sure the users that should not be assigned issues
are not in any groups that allow issue assignment.

I would like to be able to do something similar. Perhaps it is a permission? I would like the ability to disable certain users from being assigned/reassigned issues.

For me I'd like to see:

• An option to disable users which in effect prohibits them to login, be assigned issues, receive notifications, subscriptions etc....
• Emails sent to the JIRA system from the disabled user will not be processed by any JIRA services e.g. Comment Handler, Issue Creation via Email etc.
• Filter options for the "User Browser" for "All Users", "Active Users", "Disabled Users" and even to filter by group or role (3.7).
• The option to enable a disabled user.

Another reason for having a 'disable' flag: When a user has subscriptions and has checked "Email zero results" when subscribing, then JIRA will continue to send them empty subscription emails.

Another use for a 'disable' flag would be in conjunction with the POP/IMAP mail handler, which creates users automatically for the 'From' address. These automatically created accounts have a random password set initially, but the reporter could click the 'Forgot email' link and access 'their' account. Sometimes this is not desirable, and users created automatically from email should be disabled by default.

This will be a big issue for us also. I am in the process of importing a very large number (>150,000) of issues from 2 seperate repositories. In the process, about 2000 users will be created of which only 50-75 are still with the company. User management seems very difficult with that many users.

Things I'd like to see when an account is disabled(mostly what others have said):

Login disabled
Never send email to disabled account
Option when disabling account to bulk re-assign issues.
Option when disabling to remove user from all groups.
Account is still searchable(user picker can still find them, but only when searching)
Option to re-enable account.
xmlrpc or other mechanism to automate disabling(important when synching user management with external ldap/ad)

Hey Matt - I see you've stumbled on to JRA-8175 here too.
Anyway, wouldn't it be easier to have I.T. give you a fake email address that you can use, that won't generate errors? It'll just build up in a mailbox that nobody accesses.

Wow! I didn't know Jira doesn't like this construction: $

, without the space. So remove the space where it is used below.

ROOT_DIR=/home/jira/atlassian-jira-professional-3.1.1-standalone/atlassian-jira/WEB-INF

MYCLASSPATH=$

/lib/alt-0.07-jdk1.3.jar:$

/lib/oscore-2.2.4.jar:$

/lib/javacvs-20040721-patched.jar:$

/lib/commons-lang-2.0.jar:$

/lib/ofbcore-share-2.1.1.jar:$

/lib/osuser-1.0-dev-28Jul04.jar

1. Compile the affected files
   cd <srcdir>/jira/src/java
   javac -classpath $ { MYCLASSPATH }

   com/atlassian/jira/notification/DefaultNotificationSchemeManager.java

Responding to Neil: yes, our Exchange server will send mails to the bugs account about delayed sending of the email and then warnings appear every minute in the Jira catalina.out logfile. Example of such a warning:

catalina.out.1:36:2005-10-06 10:11:09,289 WARN [service.util.handler.NonQuotedCommentHandler] This user is not in jira so can not add a comment: System Administrator <postmaster@venturiwireless.com>

However, if you have the source code, here's a workaround to filter all users who's email address contains "example.com", the official bogus address.

From Atlassian Support (Brian Nguyen )
Sent: Thursday, October 20, 2005 8:57 PM

Hi Matt,

Unfortunately, modifying the source code is your only option at the
moment. To do this you should only need to modify the setRecipients
method of DefaultNotificationSchemeManager.java.

Matt's notes:

I've attached the modified file for Jira 3.1.1 Professional (the method is actually getRecipients). To compile it, you ought to use the full maven project environment, but I also found that this works:

ROOT_DIR=/home/jira/atlassian-jira-professional-3.1.1-standalone/atlassian-jira/WEB-INF

MYCLASSPATH=${ROOT_DIR}/classes:${ROOT_DIR}/lib/alt-0.07-jdk1.3.jar:${ROOT_DIR}/lib/propertyset-1.3.jar:${ROOT_DIR}/lib/oscore-2.2.4.jar:${ROOT_DIR}/lib/log4j-1.2.7.jar:${ROOT_DIR}/lib/javacvs-20040721-patched.jar:${ROOT_DIR}/lib/atlassian-core-2.2.9.jar:${ROOT_DIR}/lib/commons-lang-2.0.jar:${ROOT_DIR}/lib/ofbcore-entity-2.1.1-atlassian-06122004.jar:${ROOT_DIR}/lib/ofbcore-share-2.1.1.jar:${ROOT_DIR}/lib/atlassian-ofbiz-0.1.9.jar:${ROOT_DIR}/lib/osuser-1.0-dev-28Jul04.jar

1. Compile the affected files
   cd <srcdir>/jira/src/java
   javac -classpath ${MYCLASSPATH} com/atlassian/jira/notification/DefaultNotificationSchemeManager.java

Just wondering, Matt... if the email is non-existing, like nobody @ jira.com ... does your email application send errors somewhere? That's what I do for employees who have left. I never heard any complaints from I.T. about emails with invalid addresses.

This issue has been open for 3 years! (JIRA-931) Any sense yet of when it might appear, if ever?

I am now going to have to modify source code to stop emails being sent to departed users

~Matt

I would also like to be able to disable users so they don't show up in the drop down boxes. However, I don't want to delete the users for historical purposes. Also, deleting would require reassignment which I also don't want to do.

User archival would be great too so that user management is easier.

Maybe something like archived versions would work well here. I would also like to be able to hide the disabled users in the user browser.

Very interesting feature for large companies that have a lot of people coming in and out.

Things disabled user should NOT be able to do:

• Login
• Be assigned an issue
• Get Notifications

Things which should still work for disabled users:

• be adressable for Filters, Searching, etc.

When a user is disabled, they should also cease being sent notification emails (something the delete-groups workaround doesn't address).

Abillity to delete a user without losing (closed) issue history is important. Reassigning those would not be correct, and people do change jobs once in awhile...

Giving this issue a more specific summary so it doesn't get lost.