When should I be deleting a tenant's data?

#1

So building out an app and it’s time for the “oh crap - I’ve got data that I need to delete when the tenant is no longer a customer- when should I delete it?” discussion. Some of this is a recap from discussions I’ve had with other vendors and what I’ve done in the past - but I would love to get Atlassian to speak up (and maybe prompt Atlassian to have some public discussions about it).

The general approaches

/uninstall directly

The easiest approach is to delete when the customer uninstalls the app. But what if they’re just temporarily removing the app? Or worse - the uninstall hooks gets accidentally triggered…

/uninstall with a delay

To combat that - wait 30 days or something after the uninstall. Then delete. But… not all instances trigger a /uninstall - if Atlassian deletes the instance - we don’t get the /uninstall call.

poll for access

This is the most official suggestion I’ve heard. Basically poll each day and then after X days of not having access - delete the data.

look at the license data

Have the app connect up to the marketplace (using the non app token passwords) and download the license report and then match up the SENs. Then at expiration - delete the data. However the license data in the marketplace doesn’t always match up with the license in the app instances (jira has a couple of days longer).

Also connecting an app up with the marketplace like that scares the crap out of me from a security perspective.

Don’t F the customer

Polling and uninstall hooks all seem to also to potentially be a way to “f* the customer”. As a customer I might have temporarily uninstalled the app for whatever reason but I’m still paying for the license. I would at that point expect my data to stay (since I’m paying for it).

PS. Let’s not forget the data that’s stored in the instance

I would be amiss if I didn’t mention all of those content properties that I might have set in the instance - after I’m uninstalled or lose access - I can’t delete those. :frowning:

So what to do?

I really don’t want to have any data longer than necessary but at the same time I can’t come up with a good way of detecting when to delete things.

Help?

15 Likes
#2

Tagging folks at Atlassian that might be interested in the topic (or know somebody that might). @akassab @rwhitbeck @nmansilla @mpaisley

#3

Thank you @danielwester for raising this issue. I have struggled with that before: ACE and uninstall lifecycle event .

Clear guidance from Atlassian would help a lot.

#4

@danielwester, thank you for sharing!

We use the " /uninstall with a delay" option.

However, you just made me sad with the fact that we do not get it “if Atlassian deletes the instance”. We didn’t realize that before. I feel that Atlassian should fire the “/uninstall” or some other webhook in this case.

Cheers,
Jack

#5

It gets even worse - if an instance is restored - you’ll get a new installation with a new clientKey (but same SEN and license as before). Which means that you have zombie data sitting in your database until you manually clean it up.

#6

To try and mop up all the edge cases we also track the last time the install hook was fired and manually publish a new descriptor every quarter to see what tenants are absent

2 Likes
#7

Same here. We also have a hard time cleaning up data of instances for which we didn’t receive uninstall webhooks.

We try to clean up by checking the licensing status, but obviously this only works for licensing-enabled apps.

Even detecting if an instance that we have a tenant record for still exists is not trivial at all because there aren’t any defined HTTP response codes when polling that instance’s base url (the instance could be active, gone, sleeping, temporarily not available, …).

Some ideas:

  • It would be really great if Atlassian could provide a central (not on the instance) endpoint where apps could retrieve the status of an instance for example by providing the instance ID.
  • Another nice-to-have could be a /request-data-removal webhook that can be triggered by instance admins in the UPM for each app. This would enable them to manually delete their data before they uninstall an app.
5 Likes
#8

Our app ProForma stores all data in Jira entity properties, so when a customer uninstalls we cannot access their data any more.

That solves the problem for us because we don’t hold anything once a customer has left, but it could be a problem for them. If they want to get rid of their ProForma data after they uninstall then they’re too late — we can’t access their Jira instance any more so we can’t delete it. Jira doesn’t know what things our app wrote so it can’t delete it either.

Perhaps one way to solve it would be for Atlassian to reinstate our app’s access to Jira APIs when someone requests delete. Perhaps better, though, would be if data our apps store in Jira is marked as being owned by the app. That way Jira could provide a button for administrators to delete it without our app having to be involved.

100 app property limit should be lifted
#9

@daniel

Just chiming in to understand this better. Am no expert in this topic, but I would say I have vested interest in it :slight_smile:

How will a customer continue to pay for license after uninstall? I assumed Atlassian will only invoice them till the day an app is installed in their tenant. But that might just be me not understanding how this all works.

This is interesting. Without the app installed in a tenant, is this data even accessible to the customer?

#10

Are you sure you want the answers to these? :smile:

You can uninstall an app and continue to have a subscription. Some customers make use of this to either remove apps temporarily while they troubleshoot functionality and/or if they’re not ready for something they’ve built/integrated isn’t quite ready yet on an instance. It can also happen when an administrator doesn’t have billing rights on a system (which happened to me the other day) - uninstall the app as an admin - the billing person has to remove it.

As far as the content properties - I’ve been asking this for a while now and from what I know/been told:

  • Issue properties are available for anyone that can access the issue (this involved editing/deleting).
  • User properties are available for admin and the app that creates it (or so I’ve been told by jira devs) - there’s no documentation supporting this).
  • Add-on properties are available for admin and the app that creates it (this is documented).
  • I have no clue about the properties - but I’d imagine that they’re like the Issue Properties)

But all of that said - there’s nothing stopping me from doing an export from a jira system and getting all of the properties from the zip file.

1 Like
#11

We would also be very interested in this feature. Mostly, we would like to get a webhook whenever a Jira instance is terminated or (as @danielwester mentioned) restored.

I would suggest all the interested vendors to also vote on this issue: https://ecosystem.atlassian.net/browse/AC-863 as this has been in the backlog for quite a while now.

#12

I have build a cleanup system around the data available in the marketplace. I run a daily job to update all the SENs of the known tenants of the app. And have another daily job that will query the marketplace for SENs of licenses that where inactivated 180 days ago and will delete the tenant data but not the Atlassian host information as this is required in order for a future install event hook to be properly processed.
There are some tenants that don’t have a SEN and I have not yet developed a good solution for this, but at least with these two daily jobs, I can cleanup tenant data 180 after yet uninstalled the app. This also gives then time to 're’start where they left off when they reinstall the app.

#13

Encrypt all data at rest where decryption is linked entirely by both a client secret and one you have linked to their licence.

No licence and they have no access to the data and you don’t have liability of access to their unencrypted data.

Treat a decrypted cache layer as “in transit” if you need to improve latency. Cache lasts X hours.

Doesn’t absolutely remove data storage on your systems, but you could have a retention policy to suit your/customers best case.

1 Like
#14

Unfortunately we don’t have a single unique shared secret that we can encrypt by. Otherwise that would be awesome in the short term (I would still need to delete things at some point).

#15

I guess this was a moving forward from here point.

It’s been a technique we’ve been applying for PI data for a while. Lends itself well to auditable access ledgers also.

1 Like
#16

Anyone at Atlassian that have some suggestions?

1 Like