Hi there,
When getting group members via wiki/rest/api/group/{groupName}/member on our internal instance I noticed that there can be deactivated users. In the Atlassian UI these are greyed out and clearly deactivated, but for apps there’s no clean way to identify whether a user is deactivated:
The /wiki/rest/api/user?accountId={accountId} endpoint doesn’t reveal any more information.
From what I can tell, my only chance is to check whether the name of the user ends in (Unlicensed) since there is no active boolean value or something like that. 
Does anyone know whether this is a reliable workaround or whether this string is localized. I.e. might a german deactivated user end in (Unlizensiert)? Or do you know a better way for checking whether a user is deactivated?
Cheers,
Sven
Have you tried /wiki/rest/api/user?accountId={accountId}&expand=operations ?
(Don’t know if that will work or not).
5 Likes
Ahhh… Could’ve found that myself. 
But that seems to be it, thanks!
With ?expand=operations deactivated users seem to have an empty operations array. Also works on wiki/rest/api/group/{groupName}/member.
2 Likes
Thanks for raising, this. It’s a problem in other situations as well. For example, expanding permissions fetching a space you get deactivated users as well. If you try to create a space with the same set of permissions the REST API just gave you, it can blow up with a 500 error when these users are present. Filtering out users with “(Unlicensed)” in the name is not reliable, either – that terminology changes over time. For example, it used to read something like “(Former user).” The only way I have found to prevent that scenario is to tediously check every single user for validity with the user API before sending them back to Confluence 
1 Like
Whilst I’m not familiar with the Confluence source code, I dug around and found a file containing I18N variants of “Unlicensed” and some logic for surrounding this in brackets.
@sven.schatter, I see you’ve accepted @danielwester’s solution of calling /wiki/rest/api/user?accountId={accountId}&expand=operations, but does that mean you’ve got an n+1 performance/scaling issue whereby you get all the group members and subsequently have to make separate requests to get further details? If so, I assume the solution you’re really looking for is for Confluence to add an extra property indicating the license state to the user object returned by /rest/api/group/{groupName}/member?
2 Likes
Hi Dugald,
appreciate you checking in on this as well! 
Luckily, the expand URL parameter also works for the group members REST API:
Of course having a boolean value that represents users being active or not would be much more intuitive, but now that there’s this thread people should at least be able to find this solution via Google. 
Cheers,
Sven
2 Likes
Great - thanks @sven.schatter
1 Like
A boolean indicating this would be very valuable, IMO, since I would hope that it would be applied anywhere that a user object was serialized to JSON, such as in the space permissions example that I gave.
1 Like
Thanks for confirming this @BobBergman. I’ve created CONFCLOUD-69909 for this. For convenience, here’s the description:
Issue Summary
The shape of the user objects in the response to /wiki/rest/api/group/{groupName}/member does not include a field to indicate the status of the user (active, deactivated, system, ???).
Steps to Reproduce
- Log in to a Confluence tenant
- Change the path of the ULR to /wiki/rest/api/group/confluence-users/member
Expected Results
The returned JSON includes a field “status” which identifies the user’s status as per a documented enum of user statuses.
Actual Results
No such field is returned. Some app developers may be tempted to interpret the user’s status from a suffix that Confluence adds to the displayName field. Examples are Foo (Unlicensed) and Bar (System).
Workaround
Adding ?expand=operations to the query will include the operations allowed by the user and may help some apps distinguish users as per their requirements, but this workaround may not satisfy all app use cases.
Other REST API Responses Containing User Objects
There may be other REST resources that return user objects. It seems reasonable and preferable to enhance those APIs with status information as per the member resource identified above.
2 Likes
