100 app property limit should be lifted

#1

Hi,
we are using app properties to store our app data, so that we don’t have to store data in a separate database, with all the GDPR implications. However, we are facing the 100 limit documented here: https://developer.atlassian.com/cloud/jira/platform/jira-entity-properties/#app-properties

This limit doesn’t make any sense, especially considering that every other entity property type offers unlimited storage.

Where are we supposed to store our app data if not in app properties?

Also, the HTTP error code returned when you exceed the 100 limit is misleading: http 409, which means “conflict” and, for other REST enpoints, really means “go and retry that call”.

Any chance the 100 limit could be lifted? Or any other location we should store our data?

Thanks,
David

9 Likes
#2

It would be awesome if Atlassian would revisit the entire entity property area to solve access, querability, encryption, access, purging, access etc

5 Likes
#3

The storage options being so limited and incomparable to Server has been one of the biggest points holding us back from implementing Cloud versions of some of our apps.

#4

@akassab this is an example of useless limitations that hold back app migrations to the Cloud…

#5

Would raising the limit of app properties be enough for you to be able to implement a Cloud version of your app, or are there any other restrictions that hold you back?

Could you elaborate? What features around those areas would you like to see exactly?

#6

From an app perspective - the entity properties are not really that secure (more than just than the app can view/edit them) nor are the queryable (ie give me all properties that match X - I don’t care about the actual items that they’re attached to). As well as When should I be deleting a tenant's data?

1 Like
#7

We’re currently implementing the one app that was blocked by this using our own storage. However, we pretty much waited 2 years until we were okay with making that decision because of all the consequences that come with it. For our other apps it’s more feature specific APIs missing. Since our apps are for Confluence we’ve already talked to Shrey and the team.

However, I’m sure that this limit being bigger/lifted would be a step in the right direction to unblock apps that need to store data which is not related to host product entities. In our case, customers would’ve been able to only create 100 settings entries whereas on Server they could have a couple hundreds or thousands.

+1 to what Daniel said.

The step of going from On-Premise to SaaS is everything but easy for a lot of vendors and by providing a solid storage API you would take away a good chunk of complexity from that process. As it is now, you’re pretty much forced to bring your own storage if you want to build an app that has some sort of a sophisticated feature. It is just as desirable for vendors, as it is for customers, to have all data stored on the customers’ instance. The current implementation of properties doesn’t really allow that, though.

1 Like
#8

Actually, in our case, we already store all of our data inside Jira because of the nature of our app (we provide workflow extensions, so their configuration is, by nature, stored in the Jira workflows themselves). However, we also provide “shared” behavior that can be reused across workflows and thus needs to be stored at a global level. We currently use app data storage but we’re naturally running against the 100 item limit which, in our case, is the only blocking factor. We did consider using User Entity Properties instead (which don’t have any such limit), but they are not secure at all because they can be accessed and modified by anyone, not just by our app.

I do agree with Daniel and Sven that a solid storage API (equivalent to Active Objects on the Server side) is dearly missed, but that’s a major undertaking and likely not to be offered outside of the Forge.

However, I believe raising the app property storage limit is something that could be done right away. And the limit doesn’t really make much sense since it doesn’t exist for Entity Properties.

#9

Actually, user properties can be accessed and modified only by the user the propery is stored against or by the global admin.

#10

That’s the part that worries me. Most Jira instances don’t have one global admin but more than likely multiples. The support headache involved if (and granted it’s an if) a global admin scripted something that went through and scrubbed properties (because they can) - we have no way of verifying that this happened or recovering or who did it… Until then entity properties can’t really be used for anything that won’t be a big deal if it’s lost…

But +1 on what @david2 is asking for about removing any limits though.

#11

Limits have negative impact on app development for Cloud platform. Please remove them or make them unreachable for generic apps.

#12

For us the priority would be limits, access, and encryption/security. For every app we port to cloud this is a major point of contention/discussion/distraction. I completely agree with most of what’s been said in the responses.