Importing dashboard, private vs. public Yellowfin 7.1
17 September, 2014
When i export a dashboard that is secured to "private", it is imported as an public dashboard in the new repository. I think this behaviour is wrong and absolute not secure.
While at import there is no "control" over the users and groups, i can understand that it is not possible to import the complete security tab.
A solution could be that when a dashboard is imported and indicated to be secure, that it remains "private" and that the "deleted"-rights are assigned to the user that imports the data. In this way the user stays in control about the security-process.
Another or additional solution could be, that when security is assigned to "groups" that exist in the new repository the rights are assigned to these groups as they were in the original repository. Of course, when there is no group with the delete-rights assigned, the assignment to the users who imports the dashboard is still necessary (1th solution)
While at import there is no "control" over the users and groups, i can understand that it is not possible to import the complete security tab.
A solution could be that when a dashboard is imported and indicated to be secure, that it remains "private" and that the "deleted"-rights are assigned to the user that imports the data. In this way the user stays in control about the security-process.
Another or additional solution could be, that when security is assigned to "groups" that exist in the new repository the rights are assigned to these groups as they were in the original repository. Of course, when there is no group with the delete-rights assigned, the assignment to the users who imports the dashboard is still necessary (1th solution)
Hi Peter,
Thank you for contacting with your request.
I have had a look into this for you and the reason it defaults to public, is if it is being imported into a new repository it is assumed that it is available for PUBLIC use. It is then the user's choice to keep it public or private.
I hope this make sense but please contact if you need more clarification.
Kind Regards,
Katie
Thank you for contacting with your request.
I have had a look into this for you and the reason it defaults to public, is if it is being imported into a new repository it is assumed that it is available for PUBLIC use. It is then the user's choice to keep it public or private.
I hope this make sense but please contact if you need more clarification.
Kind Regards,
Katie
Hello Katie,
i do understand the logic that the system can't make it private "as it was" when you import it in a new repository.
But making it private opens an situation where all users temporary can access then dashboard... not speaking about the option that you can forget to set the security.
So while i assume that the XML you import contains information about the fact that it is a private report, then first option i wrote can be used to have it imported "secured".
"A solution could be that when a dashboard is imported and indicated to be secure, that it remains "private" and that the "deleted"-rights are assigned to the user that imports the data. In this way the user stays in control about the security-process."
Can you consider this options to be implemented?
i do understand the logic that the system can't make it private "as it was" when you import it in a new repository.
But making it private opens an situation where all users temporary can access then dashboard... not speaking about the option that you can forget to set the security.
So while i assume that the XML you import contains information about the fact that it is a private report, then first option i wrote can be used to have it imported "secured".
"A solution could be that when a dashboard is imported and indicated to be secure, that it remains "private" and that the "deleted"-rights are assigned to the user that imports the data. In this way the user stays in control about the security-process."
Can you consider this options to be implemented?
Hi Peter,
You can actually export secure dashboards, and keep it secure after the import.
However, you will need to ensure you use a 'group' to secure the tab, not an individual user, here is why;
-If you secure a tab, and give users access.
What happens if you import this tab into a system that does not have these users?
Well, you get the tab in the DB, but no one can access it.
-If you secure a tab and give a group access.
If you import this into a system, that does not have that group, or members of that group.
A new group will be created (but no members attached).
This means you can go to the group management, see that blank group, and then add the relevant members.
Though in saying this, when migrating secure content, the user exporting/importing will need to ensure that the security policy correctly applies to the relevant environment as the content is marked as secure for a reason.
We can revisit this whole process in the future, though I think automatically giving the user (who is importing the item) access may not be the best option, as it's possible that they are importing a bunch of items, some of which they should not have access to.
I guess best practice is to ensure secured content can be migrated ok to other instances, and if so, the security policy still applies to that instance.
Hope this all makes sense and you can understand how our process currently works.
Please let me know if you still have issues with this when using groups.
Thanks,
David
You can actually export secure dashboards, and keep it secure after the import.
However, you will need to ensure you use a 'group' to secure the tab, not an individual user, here is why;
-If you secure a tab, and give users access.
What happens if you import this tab into a system that does not have these users?
Well, you get the tab in the DB, but no one can access it.
-If you secure a tab and give a group access.
If you import this into a system, that does not have that group, or members of that group.
A new group will be created (but no members attached).
This means you can go to the group management, see that blank group, and then add the relevant members.
Though in saying this, when migrating secure content, the user exporting/importing will need to ensure that the security policy correctly applies to the relevant environment as the content is marked as secure for a reason.
We can revisit this whole process in the future, though I think automatically giving the user (who is importing the item) access may not be the best option, as it's possible that they are importing a bunch of items, some of which they should not have access to.
I guess best practice is to ensure secured content can be migrated ok to other instances, and if so, the security policy still applies to that instance.
Hope this all makes sense and you can understand how our process currently works.
Please let me know if you still have issues with this when using groups.
Thanks,
David
Hello David,
thanks for this clear answer. The method you describe is logic and really make sense. I sure think this can work "secure" in the environments we have to use this kind of dashboard-security.
With kind regards,
Peter
thanks for this clear answer. The method you describe is logic and really make sense. I sure think this can work "secure" in the environments we have to use this kind of dashboard-security.
With kind regards,
Peter