Can't get the Domain of Reporter via Connect app

Jira Development Jira Cloud
, , ,
1

In the instance http://forless.atlassian.net/, I have a custom field (id 10055) of type Domain of Reporter.

This field has a non-empty value. When I make a GET request http://forless.atlassian.net/rest/api/3/search with a token (cloud.session.token) in cookies, I see in the response that these custom fields are not empty.

But when I try to get the value of this field through the Connect app that has scopes (“READ”, “ACT_AS_USER”, “ADMIN”) which uses the latest Atlassian-supported Connect client frameworks (Atlassian Connect for Spring Boot), and when I access the endpoint GET http://forless.atlassian.net/rest/api/3/search using authorization with user impersonation (on my behalf) with Jwt Bearer Token, I receive a response in which custom fields with id 10055 are empty.

I use Power BI Connector app installed on the instance that gets the empty fields due to the issue described.

An example of a Jwt token (the token can be decoded and a payload can be received), with which you can see the values ​​of custom fields with id 10055:

eyJraWQiOiJzZXNzaW9uLXNlcnZpY2VcL3Byb2QtMTU5Mjg1ODM5NCIsImFsZyI6IlJTMjU2In0.eyJhc3NvY2lhdGlvbnMiOltdLCJzdWIiOiI1Y2Y5MGM4YmE0MzU0YzBkOGU3MGNkYTgiLCJlbWFpbERvbWFpbiI6ImFscGhhLXNlcnZlLmNvbSIsImltcGVyc29uYXRpb24iOltdLCJjcmVhdGVkIjoxNjE4NDk3ODIwLCJyZWZyZXNoVGltZW91dCI6MTYxODkyNDAzNCwidmVyaWZpZWQiOnRydWUsImlzcyI6InNlc3Npb24tc2VydmljZSIsInNlc3Npb25JZCI6IjYzYWM0MWQ3LTE1ODQtNDU5OS1iMGRiLTE4NzZlNGJjMjE5OSIsImF1ZCI6ImF0bGFzc2lhbiIsIm5iZiI6MTYxODkyMzQzNCwiZXhwIjoxNjIxNTE1NDM0LCJpYXQiOjE2MTg5MjM0MzQsImVtYWlsIjoibC50b3BjaHlpQGFscGhhLXNlcnZlLmNvbSIsImp0aSI6IjYzYWM0MWQ3LTE1ODQtNDU5OS1iMGRiLTE4NzZlNGJjMjE5OSJ9.B6QSQLZ-tPR6MGdyLzt7j0a-Q4Hn1fXbf8cX7lcTukwRzAL_K2OPD4jbL7mtLZFt0geDRGOLR8QLm3-72oHfNr2MOKp1WmUnxXiEMZZH_r5bVs8d5nudD6xnWjj4kxT2la9Jq3hFOs_mXC4Jf1I_y4DQ4pdA_z86z-kGD8QngIcrP0taNqZ8XidMInFKJSEXF87vhtTgg7mj9sp1KnwlPNfP5DQM-JR1cOEdOeDkBzAaR-EWQzcSBl1lGYsTOHULlUqm9FtRyGnctswPLjsDfQ_sLSs1BS3HW5jv_ThtbWv-y4r9m4C7e-w4HNF5Iy-Pc3zuzzFcl6xi8ZPxSmmHWg

An example of a Jwt token (the token can be decoded and a payload can be received) that uses the Connect app for authorization on my behalf and with which I get empty values for custom fields with id 10055:

eyJraWQiOiJtaWNyb3NcL29hdXRoLTItYXV0aG9yaXphdGlvbi1zZXJ2ZXJcL3JkODg2OThobXBidHV2N3IiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiI1Y2Y5MGM4YmE0MzU0YzBkOGU3MGNkYTgiLCJhdWQiOiJodHRwczpcL1wvZm9ybGVzcy5hdGxhc3NpYW4ubmV0Iiwic2NwIjpbIlJFQUQiLCJBRE1JTiIsIkFDVF9BU19VU0VSIl0sImFjdCI6eyJzdWIiOiJleUpvYjNOMFMyVjVJam9pTkdaa04yRXlaVFF0T1dReFpTMHpOelExTFdKbVpqWXRabU15TW1KaFpETXhNelV4SWl3aVlXUmtiMjVMWlhraU9pSmpiMjB1WVd4d2FHRnpaWEoyWlM1d2IzZGxjbUpwTFdOdmJtNWxZM1J2Y2kxcWFYSmhMV3h2WTJGc0luMD0ifSwidXJuOmF0bGFzc2lhbjpjb2F0OnZlcnNpb24iOiIxLjAuMCIsImlzcyI6Im1pY3Jvc1wvb2F1dGgtMi1hdXRob3JpemF0aW9uLXNlcnZlciIsInR5cCI6ImF0bGFzc2lhbi1jb2F0IiwiZXhwIjoxNjE5MDEyNDQwLCJpYXQiOjE2MTkwMTE1NDAsImp0aSI6IjRhM2EzMWU1LWEyMjAtNDQxOS04OTdlLWNmODI0NDYxZWUwYSJ9.dnRCNRsB0o5DPqjfyjXWe2U9SmBjH_lZvxcJp6WeLTJ8Mm1m67gDeTF55I-djTslNBw86xVtJxCJKPnGlAZTNWhATzhvZp_25IksnnNyRsgwViAHWfOktCnX0G05ZcWmsUer9jV-Xl8DUaiGHK3JmEQpThXnooWjRwfx09NGDKXq8EzeLIAiKk9w0M0mWg2bPRVG-9hjAOkrlo09bV10tYffIdLaoIFhCVME4k8eB1npJJWKnGuOY5EcU_T4DVBqBUEI562BWR3xMfoYOwkS3lh1i8Z2AWBG8-H24dx8NoporBuIZ08mZ0hC9YAhWlr30bt3g_jNHktN9rxudRVRgw

Could you please clarify why the plugin, when authorizing on my behalf and with rights (the plugin has a scope ACT_AS_USER, i.e. it can act on behalf of any user) receives empty values ​​of these fields?

Thank you!

Regards,
Luba

2

@LiubovTopchyi,

I think this is a corner case related to this field type. Both “Domain of Reporter” and “Domain of Assignee” types have special implications for privacy. Although I can’t entirely explain why some auth mechanisms allow access but not others, I do know this field has been kinda-sorta-deprecated because there are end-user requests to bring it back in the new issue view.

As such, I recommend:

  • Comment, vote, and watch that issue.
  • Consider using an alternate approach, like the email API, which does require a different App scope. Of course, this still requires some parsing of the domain from the email.
2 Likes
3

If you make a request through a Connect app it has different visibility of personal data compared to making a normal request.

In general Connect can only see personal data where the end user has said that it is visible to everyone. This includes email, which is used to populate the “domain of” type fields.

3 Likes
5

I’ve created the following internal request to have our developer documentation improved:

The developer community continue to be stumped by the impact of privacy considerations on our APIs. For example, various fields can be blank when the API request doesn’t meet certain criteria which is often inconsistent with or omitted from the API documentation.

The suggested actions to address this request are as follows:

  1. Create a guide explaining Atlassian’s privacy policy in the context of APIs. This should outline the different classifications of personal data, the way in which it is managed by administrators and end users and then the impact on APIs with regards to different types of API requests (type of authentication, app scopes, etc).
  2. The reference documentation should then be updated such that any field that is subject to privacy considerations is annotated with a reference to the guide.

The internal reference is DD-256.

3 Likes
6

This page is useful in understanding profile visibility:
https://developer.atlassian.com/cloud/jira/platform/profile-visibility/

1 Like