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

[mre at deepamehta.de]

Hey, thanks for your detailed answers.

Good to understand how the CREATE rights will be synthesized in the
machine, and that every topic must have a WS assignment in the future.

On Tue, 6 Jan 2015 17:50:01 +0100, Jörg Richter <jri at deepamehta.de> wrote:
>> 1 please explain a bit more about the relation of a Workspace to Topic
>> and
>> Assocation Types (in 4.5) in general
> 
> Everything -- Topics, Associations, Types, Topicmaps -- will be assigned
> to exactly one workspace. (The only thing that has no workspace
assignment
> is a workspace.)

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. In 4.5 the breaking change would be, WS
assignment of types gets mandatory (but would remain a bit cumbersome, 2
loc per type) because types introduced by plugins will not have a "home"
workspace.

>> How will a plugin developer be able
>> to control the workspace assignment for topics of certain types and for
>> the
>> user (who works from within the dm4-webclient dm4-webclient)?
> 
> The automatic workspace assignment can be suppressed by appending
> "?no_workspace_assignment=true" to your request. Your plugin is then
> responsible for manually assigning a workspace (via Workspaces service).

OK, but then, how would a developer be able to do so (altering the POST
request for topics of certain types during creation) when building up on
the _webclient_ for topics of a specificy type? I guess a develoepr would
need to alter the POST request send by the dm4-webclient (on "Create") by
the means of a client-side plugin command (BEFORE_CREATE?) to supress
ws-assignments or, maybe better, alter the /define a new, her custom/ REST
Endpoint which waits for POSTs ("Creates") of certain types (and therewith
implement ws-assignment constrains for topics of certain types).

Thanks!