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?
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.
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?
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? - #8 by charlie
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.
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.
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.
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.
We use add-on properties for specifying group access to particular pages. Just realised (in the last week) that anyone can change them. This makes them useless for security related features and means that we have to back them up in our database and when the pages try to load we then have to do one or more API calls to Jira to re-test the security. As you can imagine this is bad for load times and makes our cloud versions look less responsive then the server versions.
Be prepared that there might be no REST API allowing you to check particular permission. We have stumbled across two cases like that in the past months. One of them is solved, the other one is not.
That shouldn’t be the case. App properties are supposed to be accessible and editable only by the app. Indeed, this is what the REST API documentation says – to invoke any app property method, you need to be authenticated as the app to which the property belongs.
App properties can be manipulated by a malicious authenticated user (for example, by making REST calls through the developer console). For this reason:
Don’t store user-specific data in app properties (particularly sensitive data).
Be defensive when retrieving app properties, and don’t assume data consistency (arbitrary keys may be modified or deleted by users).
Basically that a user that is logged in can access/manipulate properties through AP.request in the console.
@kkercz it’s as @danielwester stated. I even tried it with a non-admin user running the AP.request command and updated the app property. I assume it was because I did a right-click and inspect on a less secure page (for the plugin) and ran the AP.request there.