Ticket #927 (closed Enhancement: fixed)

Opened 5 years ago

Last modified 5 years ago

Collaborative authoring in private views (v2)

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.8
Component: DeepaMehta Standard Distribution Version: 4.7
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 5 Area: Data Model
Module: deepamehta-topicmaps


DM's core virtue is personal views. Another central feature is collaboration. But the current access control mechanics and the Webclient's GUI principles do not combine these two features very well.

What is currently not well supported: collaborative authoring (that includes create/edit/delete content) while retaining the principle of personal (that is private) views. Currently (as of DM 4.7) private views exist exclusively in the user's Private Workspace. Things created there are assigned by default to the private workspace as well. As a consequence this content is not editable by anyone else. Custom workspace assignments are possible only by extra efforts on the part of the plugin developer.

#924 addressed this very issue already and aimed to solve it by attaching further configuration info on a per-type basis. But this has proven problematic for several reasons (see the #924 comments).

After discussion we found a proper solution. Basically it consists of attaching further configuration not on a per-type basis, but per-topicmap: each topicmap gets a new flag called Private. If this flag is set for a topicmap that is assigned to a non-private workspace (that includes Confidential, Collaborative, Public, Common), the topicmap will still be private. That is it will not be visible (not appearing in the Topicmap menu) for anyone but the creator of the topicmap. If the Private flag is not set the topicmap behaves just like before.

This way the user effectively can create private topicmaps within a non-private workspace. Consider for example the public CROWD workspace: the user can create a private topicmap there while the content created there will still land in the CROWD workspace (as it is currently selected), and thus is available for collaborative editing.

GUI: the New Topicmap dialog is extended by a checkbox labeled "Private". It will be selected by default. This default let the user benefit from DM's core virtue of personal views by default. If switched off the topicmap will behave just like before (as of DM 4.7). The creator of the topicmap is able to change the "Private" setting afterwards (anytime). For private workspaces the flag makes no sense, that is the "Private" topicmap checkbox is disabled.

Migration: when upgrading to DM 4.8 the "Private" flag for existing topicmaps will not be set. Thus the topicmaps behave just like before. (The creator of the topicmap will still be able to make the topicmap private afterwards.)

Change History

comment:1 Changed 5 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 5 years ago by jri

  • Summary changed from Collaborative authoring of public data in private views (v2) to Collaborative authoring in private views (v2)

comment:3 Changed 5 years ago by Jörg Richter <jri@…>

comment:4 Changed 5 years ago by Jörg Richter <jri@…>

In b83feb71f02d747b47f8bf5b56d2eec093f3605c/deepamehta:

Topicmaps: add "Private" flag to model/GUI (#927).

The New Topicmap dialog shows a "Private" checkbox.
The Private flag can be changed afterwards by editing the topicmap.

The Private flag is not yet functional.


1 new method in GUIToolkit:


Returns an object with 2 properties: dom and checked.


Topicmaps Service:

1 method has new isPrivate parameter:

Topic createTopicmap(String name, String topicmapRendererUri, boolean isPrivate)

Topicmaps REST API:

To create a topicmap put the arguments in query parameters (instead path parameters).


POST /topicmap?name=My%20private%20map&renderer_uri=dm4.webclient.default_topicmap_renderer&private=true

The private parameter is new.

See #927.

comment:5 Changed 5 years ago by Jörg Richter <jri@…>

In 20f8456fecd44896bd012cc1bfcdba4bf0822353/deepamehta:

Adapt Topicmaps menu to "Private" flag (#927).

The Topicmaps menu does not show the private topicmaps which doesn't belong to the logged in user (according to the topicmap creator).


Access Control service

1 new method:

ResultList<RelatedTopic> getTopicmaps(long workspaceId)

Returns the topicmaps assigned to the given workspace which are readable to the current user.


GET /accesscontrol/workspace/{workspace_id}/topicmaps

See #927.

comment:6 Changed 5 years ago by Jörg Richter <jri@…>

In 1d5cb491b5526d11c483b3c84829acd439dcbd0a/deepamehta:

Private topicmaps: fix logout (#927).

No error occurrs if the user logs out while a public/common workspace and a private topicmap is selected.

See #927.

comment:7 Changed 5 years ago by Jörg Richter <jri@…>

In c741172e034334592c1c306bc9a2d96025219653/deepamehta:

Topicmaps: no request on workspace switch (#927).

Optimization: no request at all when switching a workspace.
The list of topicmap topics is not refetched.

See #927.

comment:8 follow-up: ↓ 10 Changed 5 years ago by jri

Status: while the Private Topicmaps feature is basically functional issues still remain. At least:

  • Private topicmaps still appear in the Detail Panel's "related topics" list for non-legit users.
  • When a user has only READ access to a workspace she still must able to create a private topicmap in that workspace.
  • When changing a topicmap's "Private" flag afterwards the Webclient does not reflect the new state immediately. Reload is required.
Last edited 5 years ago by jri (previous) (diff)

comment:9 Changed 5 years ago by Jörg Richter <jri@…>

In 81068ae197a31173b288fd7ee95ff21954de82cb/deepamehta:

Private Topicmaps fix: related topics list (#927).

Private topicmaps do not appear in the Detail Panel's "related topics" list for non-legit users.


The getTopicmaps() method added to the Access Control service 4 days ago [20f8456f] is dropped.

Access Control for private topicmaps is now handled in the Core.

See #927

comment:10 in reply to: ↑ 8 Changed 5 years ago by jri

Replying to jri:

  • When a user has only READ access to a workspace she still must able to create a private topicmap in that workspace.

Really? Let's rethink this.

The original requirement of this ticket is "Collaborative authoring in private views". But when a user has only READ access to a workspace she can't author anyway.

Perhaps we should see the "private views" aspect independently from the "authoring" aspect?

In a way it would be attractive if a logged in user could create a private -- and persistent! -- view for e.g. a) a public workspace where she is no member of, or b) a confidential workspace (where she is a member). Note, that in both cases the user has no WRITE permission for the respective workspace.

comment:11 Changed 5 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.