GDPR and App properties

Jira Development Jira Cloud
,
#1

What’s the safest way to migrate from userId to accountId if userId was part of the property name?

I’ve implemented function that will remove previous properties and will create new one, but it sounds for me not GDPR ready solution. That means that my users should start migration procedure on their side and I have no control on this process. I’ve set apiMigrations->gdpr to false right now, and I see the only way to migrate my customers settings: is to ask them to migrate their data(or start this process silently, but anyway they should initiate it). Did anyone have experience with such issue?

#2

Do anyone have suggestions, please? Appreciate your time.

#3

@piskunovigorm - Are you talking about issue entity properties? If so, please check out ACJIRA-1723.

#4

@akassab – not actually. But I suspect that the answer will be the same. It’s about app properties. We’ve stored small user data there (for example, list of views and customization settings for each view). App properties seems to be excellent place for such settings. It’s not big data, but it’s sensitive if user will lose it. Now we have an issue cause we’ve used user.id from getUser() method as a part of app-property key.

Let’s say getUser() will return my user.id as piskunovigorm. So the url to get app-property will be something like: /rest/atlassian-connect/1/addons/{addonKey}/properties/settings-piskunovigorm.

Our team prepared code to migrate this settings. But we cannot guarantee that all users will come in time to migrate data.

#5

Why not use User Properties?
https://developer.atlassian.com/cloud/jira/platform/rest/v3/#api-group-User-properties

As of now you can still set them with user key, so I think you could do the following to migrate:

  1. Get all App keys
  2. parse user key
  3. Set User Property

Afterwards check on userproperties which also makes more sense than app properties tbh.

#6

@andreas.schmidt - thanks for your suggestion. It makes sense.

Anyway that’s not an issue. The issue is: we cannot guarantee that user’s data will be migrated if user will come only after 29 April 2019(yeah, fantastic Slowpoke). It’s not about algorithm, it’s about: “Can we migrate data without user anyhow?”.

I mentioned our case, but now I realize that it doesn’t matter what’s the case. Developers cannot migrate add-on’s data without user.

BTW, our algorithm looks similar to yours. The only difference is usage of /api/3/user/search in order to get all users. So the general view is:

  • get all users data;
  • get all app keys;
  • find keys for each user and get its data;
  • migrate data to accountId format.
#7

Why can’t you migrate user data without the user? Just iterate over all the properties you have created and convert them.
And of course for that you need to iterate over all your “tenants” (registered Jira instances)

#8

@david2 – may be I’m getting this wrong. But how can I start this process without user, that opens my add-on? As I see this process: at least one user should open my plugin in order to initiate my add-on’s code. Once again, conversion is not an issue.

#9

@piskunovigorm there are obviously many approaches to that - you could create a private REST API, a private admin page, etc., and run the conversion from that. Don’t forget to protect this using a robust authentication mechanism.

#10

@david2 – do you mean that I have access to app properties outside the jira instance? I know it can sound ridiculous, but how? As I know I should be authorized on each instance to make this thing work. It could be wrong understanding. Appreciate your help.

#11

As scary as it might sound… yes. Because when customers install your app, they grant your app access to their Jira instance, and as part of that (the “/installed” hook), you store a JWT public key that allows you to “talk” to their Jira instance “as the add-on user”. So you can use that access to call the REST API of all the instances that have installed your app. How you do that depends on how you implemented your Connect app - if you used Atlassian Connect Express for example, it becomes pretty trivial.

2 Likes
#12

@david2
Oh my…I didn’t realize that it would work. Thanks for your help. I appreciate your time.

#13

@david2

I apologize for returning to this topic. But I didn’t find a way to use publicKey in order to access Atlassian instance.

I see that publicKey is a key for Atlassian product instance, but it’s not clear what’s the implementation of REST API for it. It’s not JWT key.

Also I looked through the User impersonation for Connect apps guide. For this I should add “ACT_AS_USER” scope into description file. At the same time it will not be applied to old users and I have no any userkey.

I’m trying to do it on the base of Atlassian Connect project. If you have some information or link about how it could be done with publicKey I will appreciate it.

#14

Are you using any Atlassian SDK for your Cloud app, such as Atlassian Connect Express (ACE)?
Also, you don’t need to impersonate a user. You can do everything without impersonation, i.e. as your “add-on user”.
In your server code, how do you talk to the Jira REST API? You must be getting a REST client somehow that handles the JWT stuff, no? Aren’t you passing it the clientKey?
For example, in ACE, you can get a REST client using:
addon.httpClient({'clientKey':clientKey})
and it will take care of building the required JWT header when calling the Jira REST API. For that, it’ll look up the client instance’s public key in your registration table and build the JWT token from it.
The client key is not a user identifier but the client Jira instance identifier.

1 Like
#15

@david2, thank you so much! I missed this part about clientKey. Yes, I’m using ACE and I’ve used this with request(req) parameter. So I thought that request should be formed by Atlassian instance. Everything works for my case now and I can start migration process. Wish you all the best. You helped to fix my understanding and motivated to read code sources of this part.