In the process of using DMX, I found a problem. The administrator created a new user A, A can create a new topic map and create a new user B in private space, B can continue to create a new topic map and create a new user C in private space, C can still continue to create a new topic map and continue to create a new user D in private space, so that we can go back and forth to continue, but the administrator has no permission to view the content in the private space, unable to understand the situation in the private space.
I don’t know if it’s a bug of software design, or it’s just like this.
A private workspace is indeed this: private. No one except the workspace owner has access to it, not even admin.
To let several users work on shared content (resp. grant them READ only access) you can setup a public or collaborative (or confidential) workspace. To grant a user access you must make it a member of that workspace. Only the workspace owner (as well as other users who have WRITE access to the workspace) can create memberships.
When you create user A it will not automatically become a member of any workspace. So the only workspace she can create content in is her private workspace. Every user has a private workspace (and she can create further ones at her need).
As an example take the default workspace “DMX”: it is a public workspace, that is everyone can READ but only members can WRITE. To allow user A to create content in the “DMX” workspace you must make it a member.
Every workspace has one owner and 0 or more members. The owner of a workspace is the user who’ve created it. The owner of the “DMX” workspace is “admin”. Workspace ownership never changes. Workspace memberships do.
Please help us to improve the user guide. If you think it is unclear or incomplete please let us know. This is your opportunity to give back in open source.