Jira Cloud REST API privacy updates and migration guide

announcement
deprecation
gdpr
jira-cloud

#63

This was originally intended to be available to apps. I will get this sorted out. Keep an eye on that ticket.


#64

I’ve poked some people, I’ll keep an eye on it.

Thanks @rwhitbeck, much appreciated.

This was originally intended to be available to apps. I will get this sorted out. Keep an eye on that ticket.

Beautiful, glad to get confirmation that this was an error – thanks @bkelley!


#65

Hello,
I tried calling the get user api with “x-atlassian-force-account-id” = true in the header :
’/rest/api/3/user?accountId=someaccountId&expand=groups’

For some reason the API is not returning user avatarUrls in the response. Am I doing something wrong?

Thanks!!


#66

One of the general announcements presents a new attribute of a user object - “nickname”. However, I’ve had searched for more information about this attribute on other pages related to GDPR and didn’t find anything, including the page which details changes to particular REST endpoints.

So, is “nickname” going to be introduced or was it just an initial idea that didn’t make it through?

We’re also wondering how to handle mentions in our app. For the simplicity let’s say the app can either render textarea element with plain text or render the same text as HTML. The app allows users to mention other users - in edit mode, in textarea, we use username, while in HTML mode we render a lozenge with displayName.

This is a generic problem for both marketplace vendors and Atlassian - what is the recommended practice here?

  1. Store accountId and display nickname?
  2. Store accountId and display displayName?
  3. Store nickname and display displayName? Will nicknames (if they are to be introduced) be unique per instance and will it be possible for two users to swap their nicknames (most likely accidentally)?
  4. Something else?

Any thoughts on this are greatly appreciated.

Edit: @bkelley, @pweinberger, @rwhitbeck could you provide information regarding the existence / role of nickname attribute, please? Which of the above scenarios is recommended for vendors wishing to implement user mentions on their own?

How will Jira handle cases when a user totally restricts visibility of her/his PII? Who will be shown as author of a comment or subject of a mention?


#67

Hello,

As per this (https://developer.atlassian.com/cloud/jira/platform/context-parameters/) documentation, timezone and locale fields will be deprecated.
Can anyone tell me that how can we get timezone and locale as these fields are very important to us ?

Thank you.


#68

same here. @nmansilla - Can you please advise or get us some help here?


#69

Hi @shesse,
How can one differentiate if the sub contains the userKey or accountID before its finally removed?

This may be the user's Atlassian Account ID (added by GDPR API migration) or userKey (marked for deprecation) (removed by [GDPR API Migration](https://developer.atlassian.com/cloud/confluence/connect-app-migration-guide/)).

context is marked as optional in the documentation, what parameter within the claim can identify the accountId?


#70

Hi @nmansilla,
Since this week we are seeing no users are returned for some of our customers though they are active. We are using the /latest/user/search API, we do have the permission set correctly in the descriptors. I am not sure if there are any changes made to Cloud API’s. Any help would be greatly appreciated.


#71

AFAIK you can’t differentiate that for the sub itself. However, you could simply check if the user claim is still there => if so, the sub will likely contain a username. If there is no user claim (because it will be removed after the deprecation period), it’s likely that the sub contains the account id as stated in the migration guide. I know this is kind of optimistic, hence also prepare for the case to make a second request in case your assumption is wrong. For example, if a request using the account id field does not work, send another request using the username field.


#72

Hi @nmansilla ,

Username parameter is deprecated, and as you’ve enabled GDPR mode you’re not able to search users with username attribute, but you can fetch users(max limit 1000) with /rest/api/latest/user/search?query=%. I hope this helps, correct me if I’m missing anything here.

However, I’m not sure whether this trick will continue to support even after user privacy changes.

It would be really appreciated if you can answer my couple of questions regarding this,

  • Shall we continue using user search with % in query parameter?
  • Is there any user API which accepts multiple account ids and returns users matching those account ids? I didn’t find any in documentation, I believe it’s really useful one.

Looking forward to your response as we are stuck at these points.

Thank you.


#73

Hi @nmansilla ,

Username parameter is deprecated, and as you’ve enabled GDPR mode you’re not able to search users with username attribute, but you can fetch users(max limit 1000) with /rest/api/latest/user/search?query=%. I hope this helps, correct me if I’m missing anything here.

However, I’m not sure whether this trick will continue to support even after user privacy changes.

It would be really appreciated if you can answer my couple of questions regarding this,

  • Shall we continue using user search with % in query parameter?
  • Is there any user API which accepts multiple account ids and returns users matching those account ids? I didn’t find any in documentation, I believe it’s really useful one.

Looking forward to your response as we are stuck at these points.

Thank you.


#74

Jira does not currently have the concept of nickname, and that won’t change in the short term as part of privacy updates. (Some other Atlassian products do have nicknames, like Stride.)

Jira will always present some value for display name for users. That is, users will be able to set a publicly viewable name (which must have at least some value), even if they restrict the visibility of their real display name.

Note that of course a user’s display name is not unique. (Keep in mind that products that do have nicknames don’t require those to be unique either.) The account ID is a unique identifier that is common across Atlassian cloud products.


#75

There is an API for getting users in bulk, documented here: https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-api-3-user-bulk-get

As has been noted, that API does not support getting bulk users by account ID. There is a ticket open for this work at https://ecosystem.atlassian.net/browse/ACJIRA-1624 - watch this ticket for updates. (The work is currently in progress.)

This API will support sending a comma separated list of account IDs in the accountId query parameter (similar to how the username or key parameter currently works).


#76

Thanks @shesse. In my case I don’t need the user_id info that comes in the web hook URL params.
As of this AM I’m still seeing that user data included in web hook requests.

Is there any status on when that will be removed? Bit of a challenge to go through various HTTP endpoints and strip params from being logged.


#77

@bkelley Thanks for your response.

https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-api-3-user-bulk-get
This API is only accessible for person having Administrator Jira permission.
Would you suggest me(any API) what to do in case of person doesn’t having Administrator Jira permission(generally person having Jira software user permission) ?
If API not exist, are you planning to develop the same API and what would be ETA for the same?

Thank you.


#78

Hi. It is intentional that this functionality is restricted to admins. If you need to call this using your own user account, perhaps this is something you could discuss with the admins for your instance.

Note that Connect addons should have this permission by default.


#79

Hi @bkelley,

Thanks for quick reply. I have these follow up questions.

  1. Will i be able to call this bulk user get service using AP.request method (front end side)?
  2. What if some client has explicitly removed administrative right from connect addon user?

Why i need bulk service ?

We have Test execution screen where user can execute Test Case. We show user name who executed it inline. There can be 50/100 Test Cases in same screen.

Now if i don’t have bulk user service then i will end up calling single user service for 50 times which can screw up performance.


#80

Yes Connect apps should be able to call this. If someone removed permissions, well I guess many things could break. Generally Connect users are not shown in permission management, so it’s hard to revoke permissions for them, but not impossible.

I wonder if there is a different way of thinking about this. Consider that after the end of March there will be no such thing as a user name. Can you get account IDs in the first instance, so that you don’t need to look up account IDs from user names?


#81

@bkelley - AddOn sets the read permission in the descriptor, however it is possible that the admin removes the add_on user from Global permission. In that case the account_ids are not fetched. For us to be able to migrate users to accountId we need a way to get the Users with the accountId. If there are no permission, how do we migrate them? I have a case opened for the same and i am told its as per the behavior. Agreed, but we cannot reach out to all the customers that have the issue and ask them to provide us permission. Please advise on what API can be used so that add_on user can get the Users with the AccountId for migration


#82

@bkelley - It looks like this bulk service is also in progress. It’s not working with comma separated user keys/user names either. If i pass single account id then its working.

When do you think this Rest API will be available? We are stuck right now while fetching User name(Display name) from Account ID.