[deepamehta-devel] Fwd: Re: Upcoming DM 4.5: extended collaboration and privacy

[Jörg Richter]

Hi Malte,

On Mar 2, 2015, at 19:38, <mre at deepamehta.de> wrote:

> Ok, grabbing all my types this way worked fine, thanks for the tip. But now it would be good to have more details on how exactly 3rd-party-types need to be assigned to workspace. I did it the way i used to do  (via "Aggregation" between the type and the workspace, the workspace playing the "Child" role) but i keep getting WARNINGs on "my.domain.type_x is not assigned to any workspace ... READ .."

Since DM 4.5 you can't do the workspace assignment by manually creating Aggregation associations. The workspace assignment is now stored as a database property. The Aggregations remain there only for visualization purpose. They are not supposed to be manipulated by the user.

In the Webclient use the "Assign to Workspace" command from the topic context menu instead... Ohh, wait a minute ... this will not work. The Assign to Workspace command is only available when you have WRITE permission for that topic, which you don't have as there is no workspace assignment yet. Damn.

So, the only way to assign a type is programmatically, either via Java API or REST API. From Java you'll use this method from the Workspaces service:

	void assignTypeToWorkspace(Type type, long workspaceId)

This method assigns the following items:
	- the given Type
	- the type's View Configuration
	- the type's Association Definitions (only in 4.6-SNAPSHOT)
	- the Association Definition's View Configuration (only in 4.6-SNAPSHOT)
Note: this method does not work recursively. In case of a composite type you might want to call it for the child types as well.

There is also a REST API to make a workspace assignment:

	PUT /workspace/{workspace_id}/object/{object_id}

However this is not dedicated to types, but works generically on all topics/associations (=objects).
So, the type's View Configuration and other parts (see above) possibly need an extra request.

Note: types do not strictly require a workspace assignment at all in order to let the user create instances of it. She only needs READ permission to the type. WRITE permission is required only to let the user make changes to the type definition.

Currently DM implements a fallback: objects without a workspace assignment are granted READ permission.

> Furthermore, please tell me how exactly "Membership" could be assigned via the webclient for e.g. "User X" (while "admin" is owner of the public "Wikidata" workspace) should become "Member", i failed trying to do so various times now.

While logged in as "admin" create a "Membership" association between user x's "Username" topic (not "User Account" topic!) and the workspace "Wikidata". That is creating a regular association and then retyping it to "Membership". Leave the Role Types as "Default".

Since 4.5 only a user who has WRITE permission to a workspace is allowed to create memberships for that workspace.

Note: Memberships are effective only for "Confidential", "Collaborative", and "Public" workspaces (and are rather pointless for "Common" workspaces). Memberships have no effect with "Private" workspaces. For private workspaces only its owner have READ/WRITE access.

I hope this helps.

Cheers,
Jörg