Hi. We have a root workspace with all data; if we ...
# gooddata-cn
f
Hi. We have a root workspace with all data; if we accidentally open it, we are crashing our database. Is there a way to prevent all users from seeing that workspace on the web interface, including the admin group?
i
Hi Filip, I am afraid, this is not possible right now. May I know why do you need to keep all the data in this particular workspace, please? Also, have you considered managing such workspace under the separate organization, please?
f
we have a main (root) workspace with all of the data and then we are making a child workspace with an account filter. we are doing it this way for easier deployment of new versions of the workspace and easier maintaining of it
i
Thank you for the clarification. May I know what type of the database are you using, please? Did you have a chance to collect any error message or a log before it crashed, by a chance?
j
Interesting use case. We suggest to not grant admin (organization admin) privileges to users using child workspaces (tenants, usually your customers). Instead, grant privilege to specific child workspace to each user.
f
@Ivana Gasparekova it's just getting timeout because mssql is not jet optimized and there is lot of data
@Jan Soubusta only developers have access to admin, but we were searching way to prevent accidents if it's posible
j
What exact minimal privileges do these developers need? I mean - do they need a read or even write access to the parent workspace? And if yes, would you appreciate a setup where these developers have read/write access to the definitions of LDM/analytics but they would not have an access to execute any report?
f
we have it set up like that, but i was hoping there is an option for "hide it" from everyone
j
So do the developers need a write access to the parent workspace?
f
nobody should have access to the parent workspace. Not just writing, it should be also forbidden from reading. At the moment we have only admin user who is having access to that workspace and we are pushing changes through API call to master and then it's propagated to children
j
OK. So if the developers do not need an access to the parent workspace, then grant them privileges to all but the parent workspaces explicitly, do not grant them org admin privilege. Would that work for you?
f
yes, it is how we do it at the moment. I just wanted to check if there is some other feature/ability to completely forbid access to the parent workspace. Thank you for your answers :D
j
Unfortunately there is no such feature. I am going to record it to our ProductBoard
p
🎉 New note created.