| [che-dev] WorkspaceService create and addMember questions |
|
Bumping a question from last week http://dev.eclipse.org/mhonarc/lists/che-dev/msg01870.html Appreciate your answer. 10X, Itai From: Fonio, Itai
Hi We are implementing workspace sharing between users, and came up with some questions:
1.
Workspace creator initial permissions and roles
====================================== We would like to have the WS creator as member with admin permissions in one api call. Currently the way to achieve that is by calling two apis:
-
https://codenvy.com/api-docs-ui/#!/workspace/create - creates WS with default ACL with admin permissions
-
https://codenvy.com/api-docs-ui/#!/workspace/addMember {creator} - adds the creator as member with "workspace/admin", "workspace/developer" (because
this is the first member) Now, WorkspaceService.Create() method documentation says:
/**
* Creates new workspace and adds current user as member to created workspace
* with roles
<i>"workspace/admin"</i>
and <i>"workspace/developer"</i>.
Which would be exactly what we need, only that this is not implemented in WorkspaceService. Is there a reason for choosing not to implement that after all, or maybe adding the creator as member is expected to be taken care of in the workspaceDao.create() implementation called by WorkspaceService.create()?
2.
WorkspaceService.addMember API role significance and expansion
============================================================= We would like to introduce to the
https://codenvy.com/api-docs-ui/#!/workspace/addMember new role values that will practically alias different collections of permissions on the WS (e.g. read, read+write, read+write+updateACL). The implementation note in the api-doc defines the set of possible roles to be "account/owner", "workspace/admin" only. Is there a motivation to restrict the possible values or could it be expanded? Also, Currently the roles are saved on the member as are, with no other handling. While using the term "roles", it seems that they are defining permissions (or sets of permissions) on the target WS, and should impact the WS ACL.
Is this correct? If so, is it expected to be taken care of in the memberDao.create() implementation (called by WorkspaceService.addMember()) as no other handling is implemented? In addition:
-
WorkspaceService.addMember() forces first member roles to be "workspace/admin", "workspace/developer", which is in contrast to the allowed values described in the documentation ("account/owner", "workspace/admin")
Is that on purpose? 10X, Itai |