Hi Malte,
On Mar 2, 2015, at 19:38, <[email protected]> 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
--
devel mailing list
[email protected]
http://lists.deepamehta.de/mailman/listinfo/devel-lists.deepamehta.de
