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

[Jörg Richter]

On Jan 5, 2015, at 23:58, <mre at deepamehta.de> <mre at deepamehta.de> wrote:

> Hi dear jri!
> 
> Regarding the 4.5 release, I would really appreciate if you can find some
> time answer my following questions:
> 
> 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.)

Access Control is governed by:
	- the object's workspace assignment.
	- the workspace's "Sharing Mode".
	- the workspace's Owner.
	- the Memberships (an association between a Username and a Workspace).
	- the user's Login state.

Main differences to 4.4 and before:
	- there are no multi-workspace assignments.
	- there are no per-object ACLs. ACLs are manifest in the 5 predefined workspace sharing modes.
	- there is no per-object Owner information. Only workspaces have owners.
	- an object's Creator information is not relevant for access control.
	- there is no explicit CREATE permission. It is synthesized (see below).

For more details see:
https://trac.deepamehta.de/ticket/592#comment:1
(or ask me :-)

> 2 especially i would be interested for my plugins who build on / extend
> the functionality of the dm4-webclient for end-users
> 
> 2.1 I wonder for which of my custom topic (and association) types
> end-users will have a "Create" Permission and how not?

Generally: a user can create an instance of a type if she has READ access to the type *and* WRITE access to the selected workspace. So, there is no explicit CREATE permission anymore. It is synthesized.

Webclient: a topic type only appears in the Create menu if its "Show in Create Menu" view config is set (like in DM 4.4 and before).

If you want prohibit the user from creating an instance in the Webclient you simply can set "Show in Create Menu" to false. However, instances can still be created via REST API (provided the above conditions are met). If you want prohibit creation via REST API make sure your type is assigned to a workspace where the user has no READ access.

REST API: as the (synthesized) CREATE permission now involves a workspace a "create" request *must* contain a "dm4_workspace_id" cookie and the authenticated user must have WRITE permission for that workspace. Otherwise the request will be rejected.

> 2.2 What happens when users edit topics or associations (within the
> dm4-webclient) which already have an (automatic) assignment to a specific
> workspace (by my plugin) but the user has selected some different workspace
> in the dm4-webclient menu? What happens then to the workspace assignments
> of my topics, are they overwritten by the update request (carrying a
> different workspace id in the cookie)?

For an update request the workspace cookie is not relevant. The workspace cookie is only relevant for a create request. The created topic/assoc is assigned to that workspace then. Updating a topic/assoc does not change its workspace assignment.

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

> 2.3 Will users still be able to edit child topics (of types which have no
> workspace assignment at all, as it is now in most cases when introducing
> custom types in third party plugins)?

Editing a (child) topic is not governed by the workspace assignment of its type, but only by the workspace assignment of the topic.

Note: everything except workspaces are supposed to have a workspace assignment. Otherwise the permissions for that object could not be determined.
(With the current 4.5-SNAPSHOT there is a fallback for objects which have no workspace assignment. The workaround grants READ permission overall, but that will not remain for the release.)

> 3 also i am curious: what happens exactly if i use the assignWorkspace (of
> the WorkspaceService) method in my plugin and the object i pass in already
> has an assignment to another workspace?

The object will be re-assigned to the new workspace.
(Note: with the current 4.5-SNAPSHOT re-assignment does not yet work. It will work very soon.)
Both requirements must be met: the authenticated user must have WRITE access to both, the old workspace, and the new workspace.

> 4 if you could announce some sort of api-freeze before the 4.5 release,
> that would be very nice to have (so i have some time to adapt other
> plugins)

Yes, indeed it would be very good to gather experience with adapting your plugins before 4.5 is released. This will certainly show us where the current concepts already work and where refinement is necessary. The way I see it you can start with adaptation now.

Current state:
- The APIs should be quite stable.
- The Webclient is quite complete (except some details about Membership associations).

What is missing:
- The REST APIs are not yet fully secured resp. not all required permission checks are implemented yet, in particular for create, update, delete, re-assign operations.
- Migrating existing content to DM 4.5

This takes about 2 more weeks I guess.
Then we need about 1 week for further testing, in particular the content migration.
So DM 4.5 will be about 1 month late, unfortunately.

> Thank you very much for help & nice greets!

Thank you for all the relevant questions!

Cheers,
Jörg