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

[mre at deepamehta.de]

sharing my two questions to jri (on 4.5) for the list:

- how a type <-> workspace relation needs to look like
- how a user <membership> workspace relation needs to look like.


On Wed, 7 Jan 2015 17:28:25 +0100, Jörg Richter <jri at deepamehta.de> wrote:
> On Jan 6, 2015, at 20:10, <mre at deepamehta.de> <mre at deepamehta.de> wrote:
> 
>> So this would mean (to me): all of my ~200+ type definitions which have
>> no WS assignment yet must get assigned to some workspace by the means
of
>> an upcoming imperative migration.
> 
> Yes, that's true.
> DM can't know to which workspace(s) the 3rd-party types belong. In the
> course of adapting their plugins to DM 4.5 the plugin developers are
> supposed to do these assignments (in an imperative migration, just as
you
> say).
> 
> To simplify the migration you can possibly grab whole groups of types
> programmatically, based on a URI prefix:
> 
> 	List<Topic> topics = dms.getTopics("uri", new
SimpleValue("my.project.*"))
> 
> That is you can use wildcards in that core service call.

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 .."

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.

Thanks & Cheers!