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

[Jörg Richter]

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.

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

Yes, I agree, the need for a "home" workspace gets even more pressing with DM 4.5. We could begin to conceptualize this feature further in #371.
https://trac.deepamehta.de/ticket/371

Furthermore #324 (Injecting Services into Migrations) gets relevant for writing the 4.5 migrations as you need the Workspaces service in order to make the assignments.
https://trac.deepamehta.de/ticket/324

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

In order to manipulate the POST request issued by the Webclient's Create menu your plugin could register a listener for the "pre_send_request" event. That event is fired each time before the REST-client sends a request:

    dm4c.add_listener("pre_send_request", function(request) {
        ...
    }

The listener argument is a "request" object, which has 4 properties:
    - method -- "GET", "POST", ... (string)
    - uri -- The request URI, including query parameters (string)
    - headers -- a map of additional header key/value pairs (object)
    - data -- the payload as send in the message body

Both, the "uri" and "headers" properties are r/w (whereas "method" and "data" is read-only). So you could examine the request method and/or URI and add the request parameter to the URI when needed:

	request.uri += "?no_workspace_assignment=true"

(Probably some more care is needed, e.g. to not have more than one ? in the request URI.)

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

Yes, indeed, that would be more straight-forward, and possibly the better choice if you're not strictly relying on manipulating the Webclient's standard POST request. You would then e.g. add a custom command to the Create menu and craft the underlying request (which includes no_workspace_assignment=true) on your own. That approach is e.g. used by the "New Workspace" and "New User Account" commands. Both need to suppress the automatic workspace assignment. Have a look at the section "REST Client Extension" in the respective plugin.js

Thank you very much for sharing your "3rd-party perspective" :-)

Cheers,
Jörg