WOW! I thought it will never be implemented. 5.5 years for such a simple thing...
I know as a product owner it is hard to set priorities... So I stop complaining. 
Thanks for doing it!!!

As of Jira 8.3.0, it's now possible to make users active or inactive using the REST API.

Please refer to https://docs.atlassian.com/software/jira/docs/api/REST/8.3.0/#api/2/user-updateUser for details.

Chris is right, this REST service should be bundled with Jira.

A client needed this feature, then I found myself here. Anyway, we added this feature to Enhancer Plugin

It is as simple as a Get request below:

/rest/jep-api/latest/user/{userkey}/activate 

The most exasperating thing to me is that this used to work before they forced everything to their REST API... At the time that they were moving stuff over to the new API, they were all "tell us if some feature isn't working in the new API and we'll fix it!" Apparently that wasn't the case though, since this critical feature is still missing over three years later...

https://community.atlassian.com/t5/Answers-Developer-Questions/Disable-user-accounts-through-SQL-API-without-having-to-shut/qaq-p/560732

Is there a plan, when this really required feature will be available in Jira itself?

We have a lot of external Users. They work for a couple of weeks/month for us. So we have to deaktivate them all manually. And this is also only possible if we disable the "Update properties from LDAP", which is also a required feature... Currently our Jira admin has a lot of work only on maintaining the user accounts. I think this should not be.

I just got an email from Atlassian saying that licensing renewal cost is going to be jumping by 10%. I'm so thrilled to find out about the "increased investment in [their] server products" that sparked said monstrous jump, especially when I remember stuff like this.

That's all great, and I'm glad that there's a plugin for it, but from my perspective, why should we spend nearly as much on a plugin as we do for the product itself, to do something that should be natively included in the product directly?

Hello,

if you are looking ability to active/deactive users using REST API please check my new plugin Extender for JIRA

Cheers

Hello all,

Is there something new for this function ?

Regards.
Bruce Dang

Hello torben.hoeft, 

Thanks for your workaround. But unfortunately, it didn't work for me.

I installed katl*-commons* plugin on to the server and tried to activate user with the given REST URL, but it didn't work for me. Getting below exception. Kindly respond. Is this still working..?

I tried with PUT request as it is an update request. Of course, I tried POST also but it didn't work.

 
<status>
<status-code>404</status-code>
<message>
null for uri: https://url.com/rest/keplerrominfo/commons/latest/api/runScript?script=admActivateUser(%22username%22);
</message>
</status>

3 years ago the first comment? For a such simple function???

Please close the ticket if you don't want to support this function! 

Is there any improvement on this thread? Was this fixed or still not? Is there any work around for this? 

dvarela, yes, that it does. So it's kind of a rather large pain to have to touch enable/disables manually all the time, when everything else is done through the API.

I suppose the number of "active" users affects the number of licenses required, doesn't it?

OMG, this is going for three years and there doesn't seem to be any signs of life from Atlassian. Please people, do at least step in! Is there any technical/commercial/other issue we are not aware of? Otherwise this should be a one-line-of-code work...

BUMP

bump?

Bump, any time frame on the fix for this issue?

+1

We've an usecase to migrate inactive users from Active Directory to JIRA as inactive internal users. Looking for solution to make user inactive during creation with REST API.

This should definitely be made available, extremely important functionality missing!

Also, why are the dupliacate issues "major" but this one is a "suggestion" ??

trying to bump the issue in the vain hope that it'll get picked up soon... definitely makes it a pain that something simple like this doesn't work...

This case was long time ago, so I tested the curl way from Atlassian support again; With that command I can de/activate user in Crowd OK (observed via Crowd Users view). I think it will take some time (defined in connector?) until the status change is transported to Jira.

@J.M.Roth it's true. They seems ignore this. @Mika Nokka it doesn't update "active" field at all.

I had similar issue a while ago; I wanted to deactivate users after some inactivity period. I ended up writing Groovy Service to get it done.

However the Atlassian support kindly informed me how to do it via Crowd REST API. At the time I had other solution working but I hope this helps someone with similar issue:

-----------------
curl -i -u crowd:test -X PUT --data '

' https://crowd.machinename.fi/crowd/rest/usermanagement/1/user?username=username_of_the_user --header 'Content-Type: application/json' --header 'Accept: application/json'

Please replace the following :

crowd:test with the application username and the password of the application.
replace name_of_the_user with the name of the user.
replace username_of_the_user with the username of the user

@amoschen From all the other small but annoying things and then some more (some of them highly voted), we have learned that they care about money. Putting a developer on something like this only such that we don't need complicated workarounds doesn't get them any money. They don't strive toward perfection. Welcome to reality.

@J.M.Roth then what they should care about. It's really basic thing if user management API already exist

Why would it suddenly be working? They don't care about things like this.

any update for this? it's still not working

Just hit this issue as well. I would like to extend on this report to include a bug where a POST to /user with an "active": False value does not trigger an error either. I believe that if this content is not being respected, then an error should be thrown when the application receives invalid contents in the request.

To be honest I can not understand why this hasn't been already implemented. It is a basic feature for anyone implementing a user synchronization functionality
Atlassian, please implement this.

This is of course also working for admDeactivateUser

Here is a solution which will work with a free plugin on the marketplace.
Install the free katl-commons plugin which will provide a REST and scripting interface which is really powerful. (if you are anoyed by the price explosion for the script runner - there is an alternative)

as an administrator (Basic Authentication) you can now simply call the REST URL "http://yourjira.com/rest/keplerrominfo/commons/latest/api/runScript" with the x-www-form-urlencoded script "admActivateUser("username");"
wich will in the end look like: http://yourjira.com/rest/keplerrominfo/commons/latest/api/runScript?script=admActivateUser(%22username%22)%3B

More information can be found here:
https://confluence.kepler-rominfo.com/display/SIL/Common+REST+Service
https://confluence.kepler-rominfo.com/display/SIL/JIRA+Administration

I hope this is a solution everybody can live with until atlassian will provide this basic functionality

side note
We used kepler for the database custom field only and have also script-runner in place. I am currently evaluating if we will replace script-runner with the kepler SIL scripts because the scripting effort is much less with SIL. The following site is a short introduction and compares the effort in scripting of Jython (22 lines of code) and SIL (4 lines of code) http://atlassian.techsolcom.ca/fr/actualites/entry/unleash-the-real-power-of-jira-with-sil-the-simple-issue-language

FWIW, When it comes to cleaning up the license count, it seems to be enough to remove a user from all the groups (including and especially "jira-users"). The license count seems to reflect that.
As long as using the REST API is impossible to disable the account, you can use the workaround of removing the user from all groups using the API. I haven't tried and I wouldn't be surprised if that again was not possible for some reason but I thought I'd share my thoughts and findings.

@torben.hoeft I believe everyone who has posted/voted here is potentially interested

This is still a pain and from what I can see nothing changed in 7.x
Working with avatars etc. via the REST API and crap like that works and is not experimental but administering users is not... how come???

Who is "we"

We have extended the REST API with this functionality. I'll check if we can put this for free on the marketplace or at least make it public on bitbucket.

If interested please leave a comment

Is anyone even looking at this? How many vote are needed?

+1 Very needed feature!

as a transitional solution we have written a small Plugin which offers a REST API to change the value.

Could update any method or provide full api for us?

in the REST documentation is written "Modify user. The "value" fields present will override the existing value. Fields skipped in request will not be changed."
If I do a GET on the user, I can see that the user is "active": true or "active": false. So I expect that I can update this values with a put.
Please make this available or do a better documentation. I prefer the first option

I definitely could use this.

This is much needed. We need to mark users that no longer work with the company as inactive in an automated fashion. It is a shame that it is not included in the API.

I use script runner scripts to do this nowadays

The absence of this field in the API makes migration from an old system to Jira a pain. Users that existed in the old system but no longer work for the company and therefore are not present in Jira need to be created in Jira for the migration purpose. This can be automated but since the field is missing, all added users need be set to inactive by hand afterwards.

Not that I know of

@Matt Doar

Is there a workaround at all?

-Thanks

This is really painful to workaround.

The same problems applies for username, which is supposed to be updated this way (6.2+)

i just tested with

true/false aswell it gives same result

this to be excact

error.no.value.found.to.be.changed

-Thanks