Forum Discussion
persistProperties and stored data persistency
Hi kenwang,
Properties are only intended to be persisted in edit mode, as they are bound the the visual's metadata and are not user-specific, so a save is required to the report for them to remain.
If you have multiple people reading the report and setting their preferences, this would result in everyone's changes getting lost one ofter the other (if this were possible) as you can't guarantee when the report was last opened by a user, and what state the properties were in when they did, meaning that earlier changes from one user might be overwritten by another user.
This is the kind of thing that something like cookies are ideal for, but unfortunately they are not enabled in the visual sandbox.
Ii's possible that the local storage API might be something that could be leveraged, but this has a high bar to entry (visual must be certified and whitelisted by visuals team).
Other than that, it might be possible to store/retrieve user preferences via web services, but this comes with its own security challenges, particularly if wanting to submit to AppSource, as you'd need to ensure reliability and security of such an infrastructure, as well as establishing some kind of user-specific token. Additionally if you were submitting to AppSource and looking to certifiy, this would count as an external call and would be likely to fail.
In short, I don't think so, there is, unfortunately 😞 But, you could try asking the team directly if they have any other thoughts on this - [email protected]
Regards,
Daniel
Hi kenwang,
If you're refreshing the browser, have you ensured that you’ve saved the report first? It looks like you are persisting correctly (as you've confirmed that objects are preserved nd restored when navigating pages prior ro refresh - this means that the props can be correctly retrieved when the constructor runs, which is all you should need to worry about) but if you don't save the report before refreshing the entire web page then this is essentially reloading the entire report without saving changes. This would have the same effect for any visual, custom or otherwise. I'd suggest testing saving the report before you reload the page and hopefully this should work for you.
If you're using F5 to try to refresh the visual, you should actually click the reload button on the visual itself rather than the entire page, as there is no hotkey bound to this and you'd ideally want to avoid refreshing the entire page (and report) unless there's a very specific reason for doing so.
Regards,
Daniel
Thank you and much appreciated. Yes indeed, if I clicked "save" before refreshing, the properties will persist.
Maybe I am tackling my requirements wrong. What I am trying to do is to have user's interaction perserved (without going into edit mode). I wonder if this is possible at all.
What is happening is that I am implementing an initial auto-layout to display objects on a chart (when it's first loaded). The users are however, encouraged to "drag" the items to their position of choice. I am trying to preserve the user's choice. Will this be possible?
Regards,
Kenneth
Hi kenwang,
Properties are only intended to be persisted in edit mode, as they are bound the the visual's metadata and are not user-specific, so a save is required to the report for them to remain.
If you have multiple people reading the report and setting their preferences, this would result in everyone's changes getting lost one ofter the other (if this were possible) as you can't guarantee when the report was last opened by a user, and what state the properties were in when they did, meaning that earlier changes from one user might be overwritten by another user.
This is the kind of thing that something like cookies are ideal for, but unfortunately they are not enabled in the visual sandbox.
Ii's possible that the local storage API might be something that could be leveraged, but this has a high bar to entry (visual must be certified and whitelisted by visuals team).
Other than that, it might be possible to store/retrieve user preferences via web services, but this comes with its own security challenges, particularly if wanting to submit to AppSource, as you'd need to ensure reliability and security of such an infrastructure, as well as establishing some kind of user-specific token. Additionally if you were submitting to AppSource and looking to certifiy, this would count as an external call and would be likely to fail.
In short, I don't think so, there is, unfortunately 😞 But, you could try asking the team directly if they have any other thoughts on this - [email protected]
Regards,
Daniel