@JatinChopra thanks for the feedback.
Some context: all operations have been done via the browser dev tools from within a Connect iframe using AP.request. The creation, modification and deletion have all been executed from the same Connect app iframe. However, after creating the user property I logged out from Confluence and logged in with a different user and this user was able to read, modify and delete the property.
So as mentioned in my previous comment I don’t see a real value for this new API as its current functionality can already be “simulated” with the app property API (just to avoid misunderstanding: I’m referring to App properties API). The app property API even supports the app isolation which means when I try to access an app property of app X from a Connect iframe of app Y, the API returns a 404.
For storing data in a user property I would currently see the following 2 use cases which can’t be implemented with the new API:
- Storing some data in my properties which other Confluence users are allowed to see but only I can modify or delete. For example some profile information you would like to share with others. But you would definitely expect that no one else is able to change it.
- Storing private data in my properties which can only be accessed by me. This could for instance be used for preferences for certain features of an app as mentioned by Candid or generating personalized results. Such information could be sensitive and shouldn’t be accessible by others.
Of course, other devs might have different needs.