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 still appear in the system for reporting purposes (i.e. find me all issues where reporter=jdoe OR find me all issues where assignee=jdoe). These disabled users also should show up in the greenhopper the agile planning board as an assignee IF they have issues assigned to them. New issues should not be able to be assigned to them however.