Ticket #592 (closed Enhancement: fixed)

Opened 7 years ago

Last modified 6 years ago

workspace should have configurable ACL attributes

Reported by: JuergeN Owned by: jri
Priority: Major Milestone: Release 4.5
Component: DeepaMehta Standard Distribution Version: 4.1.3
Keywords: Cc: dgf, Malte, carolina
Complexity: 13 Area: GUI / Usability
Module:

Description

As described in the wiki (https://trac.deepamehta.de/wiki/JuergeN/Philosophy) a workspace should have UI configurable ACL attributes:

  • private (only owner/user can access/read/edit the workspace)
  • shared (the user/owner can invite other users to read/see the contents of the workspace)
  • common (the user/owner can invite other users to edit the contetns of the workspace)
  • public (all data can be edited by all other users)

Change History

comment:1 Changed 7 years ago by JuergeN

Malte, jri and I have been refining this idea at our last meeting. Instead of four different types of workspaces we now have five. We have also tryed to find a better wording for them. Each of the five workspace types has a predefinied set of ACL settings, which apply to all objects that are assigned to the particular workspace instance. Any object can only be assigned to one workspace instance. Any user may be member of various workspaces.

The ACLs are defined for three entities: owner, member and everyone (like in unix: user, group, other). Member is the member of the workspace that the object is assigned to. The ACL definition is only based on read and write, where write includes create, read and delete:

# Type of Workspace Owner Member Everyone
1 private write --- ---
2 confidential write read ---
3 collaborative write write ---
4 public write write read
5 common write write write

1 = Only the owner (user) can read and write the contents of her private workspace.
2 = The owner (user) can read and write the contents and all members can read the contents of the confidential workspace.
3 = The owner and all members of the workspace can read and write the contents of the collaborative workspace.
4 = The owner and all members of the workspace can edit (read and write) the contents and the public can read the contents of the public workspace.
5 = Everyone can read and write the contents of the common workspace.

When creating a new workspace, the user shall select the type of workspace through e.g. radio buttons. Maybe we can find color codes or icons that can indicate the ACL setting for every type of workspace.

  • Per default the creator of a workspace or object is the owner of it.
  • To reveal an association, the user must have read access to the association as well as read access to the 2 topics involved.
  • To create a new topic intance, the user must have read access to the workspace of the topic type and write access to the current workspace.
  • To edit an existing topic type, the user must have write access to the workspace the topic type is assigned to.
  • To re-assign an obeject to another workspace, the user must have both: write access to the object's current workspace and write access to the destination workspace.
  • To make a user a member of a workspace, the user must have read access to the user instance and write access to the workpsace. So a user can "join" a workspace herself if she has write access to that workspace. Another user can add the user to any workspace where she has write access. (But not to any private workspace, which does not have any member other then the creator (owner) herself.)
Last edited 6 years ago by jri (previous) (diff)

comment:2 Changed 7 years ago by jri

Thank you, JurgeN, for reporting this!
I'm very happy with this new Access Control concept.
(I replaced "recent" with "current" 2x)

comment:3 Changed 7 years ago by jri

  • Milestone Release 4.2 deleted

comment:4 Changed 6 years ago by jri

Finally I'll begin developing this feature now!
Sorry for the delay.

comment:5 Changed 6 years ago by jri

  • Cc Malte, carolina added; mre removed

comment:6 Changed 6 years ago by jri

  • Milestone set to Release 4.4

comment:7 Changed 6 years ago by Jörg Richter

Workspaces model: add "Workspace Type" (#592).

Migrations 2 and 3.

See #592.

comment:8 Changed 6 years ago by Jörg Richter

Add "Workspace Type" selector to dialog (#592).

Not yet functional.

New render helper method:

dm4c.render.label(label)

See #592.

comment:9 Changed 6 years ago by Jörg Richter

comment:10 Changed 6 years ago by Jörg Richter

Access Control: new permission rule (#592).

Not yet functional.

BREAKING CHANGES

Every workspace must have a "Workspace Type" assigned.
Plugins which introduce its own workspace must be adapted.
See Migration3.java of Workspaces module.

See #592.

comment:11 Changed 6 years ago by Jörg Richter

Access Control: define "Membership" type (#592).

Access Control API

2 new methods:

void createMembership(String username, long workspaceId)
boolean isMember(String username, long workspaceId)

BREAKING CHANGES

Each topic/association must be assigned to at maximum *one* workspace.
This applies in particular to "Username" topics.

The "Membership" semantics (that is: a user is a member of one or more workspaces) is now expressed explicitly by means of a "Membership" association (between the "Username" topic and the workspace).

Access Control API

2 methods dropped:

void joinWorkspace(String username, long workspaceId)
void joinWorkspace(Topic  username, long workspaceId)

Use createMembership() instead (see above).

Workspaces API

1 method changed:

List<RelatedTopic> getAssignedWorkspaces(DeepaMehtaObject object)
-->          Topic getAssignedWorkspace(DeepaMehtaObject object)

See #592.

comment:12 Changed 6 years ago by Jörg Richter

Access Control: READ permission (#592).

The READ permission is enforced per topic/association instance.

Core API

new class:

de.deepamehta.core.service.AccessControlException

See #592.

comment:13 Changed 6 years ago by JuergeN

Hi Jörg, just to avoid some confusion and extra work, I am just not sure how to read this:

Each topic/association must be assigned to at maximum *one* workspace.
This applies in particular to "Username" topics.

The "Membership" semantics (that is: a user is a member of one or more workspaces) is now
expressed explicitly by means of a "Membership" association (between the "Username" topic and the
workspace).

From the concept we had designed together, the first part is absolutely correct:

Each topic/association must be assigned to at maximum *one* workspace.

What confuses me, is the second part:

This applies in particular to "Username" topics.

Because the users (Usename?) must explicitly be able to connect to (become member of) several workspaces. Every user can become a member of n workspaces with either read or write permission, while every _other_ topic or association can only be connected to exactly *one* workspace.

=> Just want to make sure that we agree on that!?

Last edited 6 years ago by JuergeN (previous) (diff)

comment:14 Changed 6 years ago by jri

Yes, we are fully agree on that.

A user can be member in several workspaces (of course!). Now an explicit "Membership" association is used to express that. A Username topic can be involved in several Membership associations.

In DM 4.3 there is no Membership type, but the ordinary 1-many workspace assignment semantics was used to express memberships (an Aggregation association between Username topic and Workspace topic). That is when a user is a member in several workspaces in a 4.3 installation the Username topic is assigned to many workspaces. What my original comment want say is that this state will be regarded as a corrupted DB in DM 4.4-SNAPSHOT, "workspace-acl" branch (and an exception will be thrown). That's why it is listed as BREAKING CHANGE.

So, in case you want try the current "workspace-acl" branch you must remove a Username's Aggregations manually in case there is more than one. When DM 4.4 is released this work could be done automatically by a migration.

For the moment it is not recommended to install the "workspace-acl" branch. It is still experimentally.

comment:15 Changed 6 years ago by jri

The "authoritive" spec (comment:1) is extended by this line:

To reveal an association, the user must have read access to the association as well as read access to the 2 topics involved.

comment:16 Changed 6 years ago by Jörg Richter

Access Control: adapt to PRE_GET semantics (#592).

Topic/Association? permissions are checked *before* the Topic/Association? is actually instantiated.

See #592.

comment:17 Changed 6 years ago by jri

  • Status changed from new to accepted

comment:18 Changed 6 years ago by Jörg Richter

Access Control: assoc READ permission (#592).

For the first time a public topicmap which contains partly private objects is properly displayed.

When the user is not logged in the private parts are not displayed, and neither appear in the detail panel.
Once logged in, the private parts appear.

Note: an association is granted READ permission only if the user has READ permission to all the 3 objects: the association itself AND the 2 player topics.

See #592.

comment:19 Changed 6 years ago by Jörg Richter

Access Control: fix workspace permission (#592).

The READ permission for Workspace topics is calculated properly.

Crucial refactoring: the logic to calculate the permissions has moved from the Access Control module to the Core module. This is required because the permission calculation must involve low-level Core calls (direct storage access) in order to avoid endless recursions. E.g. calculating the READ permission for a workspace topic must be performed without actual fetching the workspace topic itself (through the public Core Service) as this would involve calculating the READ permission...

BREAKING CHANGE

1 class moves to another package:

de.deepamehta.plugins.accesscontrol.model.Operation
-->
de.deepamehta.core.service.accesscontrol.Operation

See #592.

comment:20 Changed 6 years ago by Jörg Richter

Fix: default workspace has ACL info (#592).

The default workspace ("DeepaMehta") got creator/owner/ACL information.
The owner information is a requirement for the new workspace ACL rules.
As an additional effect the DeepaMehta workspace topic is now editable by members.

See #592.

comment:21 Changed 6 years ago by Jörg Richter

Access Control: fix topicmap permission (#592).

The READ permission for Topicmap topics is calculated properly.
The Topicmaps menu shows only topicmaps the user has READ permission for.

See #592.

comment:22 Changed 6 years ago by Jörg Richter

Access Ctrl: synthesize CREATE permission (#592).

At client-side the CREATE permission is synthesized from both:

  • is the respective type READable?
  • is the current workspace WRITEable?

Note: at client-side the CREATE permission is one factor to decide which types to be shown in the Create menus.

BREAKING CHANGE

At server-side there is no notion of a CREATE permission anymore.
The Operation.CREATE enum constant is removed.

See #592.

comment:23 Changed 6 years ago by Jörg Richter

Access Control: fix Create menu visibility (#592).

The Create menu has proper visibility in 3 situations:

  • webclient launch
  • login
  • logout

Pending:

  • workspace switch

See #592.

comment:24 Changed 6 years ago by Jörg Richter

Access Ctrl: fix Create menu visibility pt2 (#592)

The Create menu's visibility is adjusted once a workspace has been selected.

See #592.

comment:25 Changed 6 years ago by jri

  • Milestone changed from Release 4.4 to Release 4.5

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

In 001d9ce9f1cfcc516731e8fc929e7713247f1485/deepamehta:

Workspace service: add getAssignedTopics() (#592).

The Workspaces service has a new method:

ResultList<RelatedTopic> getAssignedTopics(long workspaceId, String typeUri)

Returns all topics of a given type that are assigned to a given workspace.

REST API:

GET /workspace/{id}/topics/{type_uri}

Append ?include_childs=true to include the topics child topics in the response.

Needed for "#592: workspace should have configurable ACL attributes".

See #592.

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

In 7c6dfb84fa59edd90112a647b36e60cdc3d47c16/deepamehta:

Show topicmaps of selected workspace only (#592).

Pending:

  • Refresh Topicmaps menu once user selects another workspace
  • Deleting topicmaps

See #592.

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

In e97faabfe3d2c89ce97091f867755983c0d3c529/deepamehta:

Fix deleting topicmaps (#592).

New utility method:

js.find(array, fn)

Returns the first array element that matches a filter function.

See #592.

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

In 567c7716618a5773898b00798eaa94a17035e7f4/deepamehta:

Refresh Topicmaps menu on workspace select (#592).

When selecting a workspace: a) the Topicmaps menu shows only the topicmaps assigned to the selected workspace and b) selects the topicmap that was previously selected for that workspace.

When selecting a workspace the corresponding workspace topic is not revealed anymore. That was just a workaround.

See #592.

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

In 1495726ef34c09bd4baf4d3472b705d23fd96be8/deepamehta:

Fix: switching workspace on logout (#592).

When logging out while a private workspace was selected a public workspace (and thus a public topicmap) is selected programmatically.

New Access Control event:

logged_out_2

We have 2 "logout levels" now (in analogy to the 3 "init levels").
This allows plugin's to orchestrate their logout actions.

See #592.

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

In 36de3b16ea6f1854f8a8657f84eb2e7de54be1d0/deepamehta:

Fix: topic selection on logout (#592).

Logging out while a private topic is selected throws no exception.

BREAKING CHANGE

Webclient method removed:

dm4c.restore_selection()

See #592.

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

In 84db7f457f861ef967bceff92691df49dcbbcda4/deepamehta:

Fix: new workspace gets default topicmap (#592).

See #592.

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

In 8b298862d4ebf749fd9f414637056b92879c4ec3/deepamehta:

Fix: permission for creating a topicmap (#592).

The "New Topicmap..." command appears only if the user has the respective permission.

The rule is the same as for regular topics: the user requires READ permission for the "Topicmap" topic type AND WRITE permission for the current workspace.

See #592.

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

In ca83449f28c40720497a0d8e1ce6d3ccd29faf60/deepamehta:

Fix: permission for creating a workspace (#592).

The "New Workspace..." command appears only if the user has the respective permission.
The rule is simple: every logged in user is allowed to create workspaces.
This rule is different from the rule for regular topics and topicmaps as workspaces are top-of-hierarchy objects.
They are NOT created in the context of another workspace.

See #592.

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

In e4ed329c35c351c753e40266cd3f16c2bd297f6b/deepamehta:

Change "Workspace Type" wording (#592).

The concept of "Workspace Type" is renamed to "Sharing Mode".
The Sharing Mode comprises the 5 instantiations: "Private", "Confidential", "Collaborative", "Public", "Common".

There are a lot of "types" in DM already. "Sharing Mode" is a more concise term.

See #592.

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

In 0dcb5cc090aa55aea65399d849945f257479e7d9/deepamehta:

Fix: page reloading (#743).

When pressing Reload the Webclient initially selects the workspace that corresponds to the URL's topicmap reference (/topicmap/{id}).

Messages like this should not occur anymore:

TopicmapsError: topicmap 2899 not found in model (workspace_id=1615)

Workspaces REST API

New request:

GET /workspace/object/{id}

Returns the workspace a topic or association is assigned to.
Response is a workspace topic.

See #592.
See #743.

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

In ba14a183118a58560b1d5cd70cc62e5f36b3a67b/deepamehta:

Access Control: add migration 4 (#592).

Migration 4 deletes dm4.accesscontrol.owner and dm4.accesscontrol.acl properties from the DB.

Note: since DM 4.5 only workspaces have a dm4.accesscontrol.owner property. Other topics/associations have not.

The dm4.accesscontrol.acl property is obsolete.

See #592.

comment:38 Changed 6 years ago by jri

For the particular aspect of managing user accounts see also #751

comment:39 Changed 6 years ago by jri

What are the requirements for a user to create a (generic) association?
It seems we have not yet fixed that.

Once we have decided upon that I'll update the "authoritive" spec (comment:1).

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

In 7ddb36cd14ea7364dc98a5598471a1a6384cb0c5/deepamehta:

Drop legacy access control code (#592).

See #592.

comment:41 Changed 6 years ago by jri

At the moment there is a bug: when you're not logged in while selecting the System workspace for the first time the Webclient throws an error.

Workaround: make sure you're logged in when selecting the System workspace for the first time.

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

In 78036e885140ccfdd95fdbb6f82f46070cd03427/deepamehta:

Refactor workspace creation (#592).

Workspace API

createWorkspace() is RESTful:

POST /workspace/{name}/{uri}/{sharing_mode_uri}

The URI is optional: the uri path segment may be empty.

new REST-client method:

dm4c.restc.create_workspace(name, uri, sharing_mode_uri)

In preparation of fixing the missed System workspace default topicmap.

See #592.

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

In a68ad77acafe1ea6d4fef99b9267cd3708465a10/deepamehta:

Fix System workspace (#592).

When no user is logged in while the System workspace is selected for the first time the Webclient throws no error.

Managing the workspace default topicmap ("untitled") has changed:

  • Each time a workspace is created (via Workspaces API) a default topicmap is created as well and assigned to the new workspace automatically. This works also outside a request scope (while system startup).
  • There is no "global" default topicmap anymore. The URI "dm4.topicmaps.default_topicmap" has no special meaning anymore.

IMPORTANT

When you create a workspace via REST API you must suppress automatic workspace assignment by adding a query parameter:

POST /workspace/...?no_workspace_assignment=true

Future versions of the REST API might not require the query parameter.

CHANGE in Topicmaps API

2 public constants in TopicmapsService:

String TopicmapsService.DEFAULT_TOPICMAP_NAME     (value is "untitled")
String TopicmapsService.DEFAULT_TOPICMAP_RENDERER (value is "dm4.webclient.default_topicmap_renderer")

BREAKING CHANGE

1 method dropped from Topicmaps API:

Topic createTopicmap(String name, String uri, String topicmapRendererUri)

Creating a topicmap with a particular URI is not supported anymore.
Use the 2-arg createTopicmap().

See #592.

comment:44 Changed 6 years ago by jri

IMPORTANT: since yesterday editing a workspace is broken.
An endless recursion occurs at server-side!

Don't try editing a workspace topic on the nightly demo installation!
(Creating a workspace is OK, but don't edit one afterwards.)

Tomorrow morning the demo installation will be OK again.

Sorry.

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

In ebeaa97b0d8f03572c3f373ea75eb39e8d25087f/deepamehta:

Fix editing a Workspace topic (#592).

Editing a Workspace topic causes no endless recursion.
It was broken yesterday.

See #592.

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

In 7459093f104cfa653c9614c95ef84d2e3a32be3c/deepamehta:

Do not enrich types with permission info (#592).

Types going over the wire are not enriched with permission info anymore.
With the DM 4.5 access control concept this is not necessary anymore. Types are just like topics.

Potentially this also makes type definitions cachable by the browser (not yet tested).

See #592.

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

In 070efcec30a00b988eae45841e4c9c0e16f6fb80/deepamehta:

Refactor creator/owner/modifier code (#592).

The internal Access Control code reflects the DM 4.5 access control concept better:

  • The "owner" applies only to workspaces. Regular topics/associations does not have an owner.
  • The topic/association's "creator" and "modifier" are purely cosmetic. The creator does not govern the access control rules anymore. Creator and owner are maintained for informational purpose only.
  • As a consequence the creator must not be faked anymore. That means it is not necessary anymore to set "admin" as the creator of things which are actually created by the system itself. These things have no creator anymore. It is just undefined.

See #592.

Last edited 6 years ago by jri (previous) (diff)

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

In d4ceee582f1262bca5aea000bb3195410e69fc07/deepamehta:

Adapt Access Control API (#592).

The public Access Control API reflects the new DM 4.5 access control concept.

BREAKING CHANGES

2 renamed methods:

String getOwner(long objectId)
->
String getWorkspaceOwner(long workspaceId)

void setOwner(DeepaMehtaObject object, String username)
->
void setWorkspaceOwner(Topic workspace, String username)

Only workspaces have owners.

1 changed REST API call:

GET /accesscontrol/object/{id}/owner
->
GET /accesscontrol/workspace/{workspace_id}/owner

Note: there is no REST API to *set* the workspace owner.

1 dropped method:

void setCreator(DeepaMehtaObject object, String username)

The creator can't be faked/tweaked. That's not necessary anymore.

See #592.

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

In 78a81d3eae5fe7fd194e554d2d5e3ae51a77a227/deepamehta:

Enforce membership creation policy (#592).

Webclient: a membership can only be created if the current user has write access to the respective workspace.
Otherwise the Membership item in the association retype menu is disabled.

Additionally a membership can only be created if the involved topics are a Username and a Workspace.

Pending:
Enforce membership creation policy at server-side (Core API).

Webclient API

1 new method:

dm4c.has_retype_permission_for_association(assoc_type, topic_1, topic_2)

There is a new client-side event with the same name.
Its listener takes the same paramters.

BREAKING CHANGES

Webclient API

2 changed methods:

dm4c.has_write_permission_for_topic(topic_id)
dm4c.has_write_permission_for_association(assoc_id)

The parameter is just an ID (instead of a topic/assoc object).
The same applies to the corresponding event listeners.

See #592.

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

In b88fdac5b75897562af50f6373bb0c232befd5fd/deepamehta:

Webclient: refactor type permission code (#592).

Webclient API

1 new method

dm4c.is_workspace_writable()

Returns true if the current user has write access to the selected workspace

BREAKING CHANGES

Webclient API

1 changed method:

dm4c.topic_type_list()

Doesn't have a permission_function parameter anymore.
Takes no parameters.

2 dropped methods:

dm4c.has_topic_type(topic_type_uri)
dm4c.has_assoc_type(assoc_type_uri)

2 renamed methods:

dm4c.has_read_permission(topic_type_uri)
->
dm4c.has_read_permission_for_topic_type(topic_type_uri)

dm4c.has_create_permission(topic_type_uri)
->
dm4c.has_create_permission_for_topic_type(topic_type_uri)

2 dropped client-side events:

has_read_permission
has_create_permission

See #592.

comment:51 Changed 6 years ago by jri

  • Complexity changed from 3 to 13

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

In 50a457713c2ee873b45e1a41393e9ee1157dab59/deepamehta:

Fix assoc creation permission (#592).

The association creation policy is enforced: if not applicable the "Associate" command does not appear, and also the create-assoc-through-dragging gesture is not enabled.

Webclient API

1 new method:

dm4c.has_create_permission_for_association_type(assoc_type_uri)

See #592.

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

In 9d90a8bc7988cd979f8e64e1485a133914428108/deepamehta:

Workspace assignment is a :1 relationship (#592).

MODEL CHANGE

The Workspace facet is modeled as single-valued: each object is assigned to *one* workspace.

Pending:
The respective migration.

Workspaces API

Re-assigning a workspace now works:

void assignToWorkspace(DeepaMehtaObject object, long workspaceId)
void assignTypeToWorkspace(Type type, long workspaceId)

The API has not changed (but the behavior has)

Facets API

2 new methods in FacetValue:

FacetValue putRef(long refTopicId)
FacetValue putRef(String refTopicUri)

Puts a topic reference for a single-valued facet. By-ID resp. by-URI.

See #592.

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

In f79a10f0533fc765f039d45c7b41cf907fc2ffe0/deepamehta:

Fix "DeepaMehta" workspace URI (#592).

de.workspaces.deepamehta
->
dm4.workspaces.deepamehta

A migration is provided.

See #592.

comment:55 Changed 6 years ago by jri

Note: creating types does not work at the moment.
It was broken 3 days ago with commit [9d90a8bc] (see comment:53).
It will be fixed very soon. Sorry.

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

In 4614196b0a35d13abd1c9119e7629a6eea3a8b68/deepamehta:

Core: fix aggregation-one update code (#592).

Formerly the core throwed a ClassCastException? when updating an aggregation-one facet 2 times in a row on the same object but with different values. A test to demonstrate the issue is included. Now this is fixed.

As a consequence creating types works again.
It was broken 4 days ago with commit [9d90a8bc].

The exception was:

Caused by: java.lang.ClassCastException: de.deepamehta.core.impl.AttachedTopic cannot be cast to de.deepamehta.core.RelatedTopic
	at de.deepamehta.core.impl.AttachedChildTopics.updateAggregationOne(AttachedChildTopics.java:380)
	at de.deepamehta.core.impl.AttachedChildTopics.updateChildTopics(AttachedChildTopics.java:243)
	at de.deepamehta.core.impl.AttachedDeepaMehtaObject.updateChildTopic(AttachedDeepaMehtaObject.java:194)
	at de.deepamehta.plugins.facets.FacetsPlugin.updateFacet(FacetsPlugin.java:139)
	at de.deepamehta.plugins.workspaces.WorkspacesPlugin._assignToWorkspace(WorkspacesPlugin.java:314)

Core API

A type model's addAssocDef() method now returns the type model (formerly void).

TopicTypeModel addAssocDef(...)
AssociationTypeModel addAssocDef(...)

This allows chaining several addAssocDef() calls when building composite types programmatically, e.g. in a test.

See #592.

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

In 85a9acacbae735981f48ed400baf693071fdac00/deepamehta:

Search topics are private (#592).

A Search topic is assigned to the user's private workspace.
Nobody can see what another user is searching for.

Pending:
Search topics created by anonymous have no workspace assignment yet.
As a consequence they are not deletable.

Note: assigning Search topics created by anonymous to the System workspace (see #756) is not practicable as anonymous has no READ access to the System workspace. She could not see her own search.

Access Control API

1 new method:

Topic getPrivateWorkspace()

Returns the private workspace of the logged in user. If no user is logged in an exception is thrown.
Note: a user can have more than one private workspace. The workspace returned by this method is the one that holds the user's password topic.

See #592.

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

In f4127c3d33e856f970bc3d09281e27e085926b4c/deepamehta:

Anonymous Search topics (#592, #756).

Search topics created by anonymous are assigned to the DeepaMehta workspace.
As a consequence they are not deletable by anonymous but by DeepaMehta members.

See #592
See #756

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

In 15f49c1be19a2d246c5edc5b01a2b422d71b6d6c/deepamehta:

Update GUI on delete membership (#592).

When a user leaves a workspace (by deleting a Membership where she is involved in) the Webclient GUI is updated in order to reflect the decreased authority.

Webclient API

1 new method in class Association:

matches(type_uri_1, type_uri_2)

Returns true if the association's topics match the given topic types.

BREAKING CHANGES

3 client-side Access Control events are renamed and have extended semantics:

logged_in    -> authority_increased
logged_out   -> authority_decreased
logged_out_2 -> authority_decreased_2

Extended semantics of the authority_decreased events: they are fired on both occasions, when the user loggs out (like before), and when the user leaves a workspace. Both occasions are combined under the semantics of "The authority of the current user has decreased".

See #592

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

In cebaa9de77d403f00e3223d498adfedd86de35d2/deepamehta:

Workspaces: add migration 6 (#592).

In case of updating an existing installation to DM 4.5: change the cardinality of the workspace facet to "one".

See #592

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

In 3fae2c6bca7d4e246874ee30de727323bcc5847c/deepamehta:

Access Control: add migration 5 (#592).

In case of updating an existing installation to DM 4.5: this migration creates the "System" workspace and sets "admin" as its owner.

For the first time you can login into an updated-to-4.5 installation. Several issues remain.

Access Control API:

5 new public constants in AccessControlService:

// Admin user account
static final String ADMIN_USERNAME = "admin";
static final String ADMIN_DEFAULT_PASSWORD = "";

// System workspace
static final String SYSTEM_WORKSPACE_NAME = "System";
static final String SYSTEM_WORKSPACE_URI = "dm4.workspaces.system";
static final SharingMode SYSTEM_WORKSPACE_SHARING_MODE = SharingMode.PUBLIC;

See #592

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

In e01eda32cce623ca13b4b09725f68cf00018643e/deepamehta:

Access Control Mi#6: convert user accounts (#592).

In case of updating an existing installation to DM 4.5: this migration converts the user accounts. That is the private workspaces are created and the various user account parts are assigned to the proper workspaces.

For the first time search is working on an updated-to-4.5 installation. Issues remain.

Access Control API:

1 new public constant in AccessControlService:

static final String DEFAULT_PRIVATE_WORKSPACE_NAME = "Private Workspace";

See #592

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

In 3b4497838ca82b75c6131c14a023b634158e19b3/deepamehta:

Access Control: refactor migrations (#592, #324).

In case of updating an existing installation to DM 4.5: this migration reconstructs the user's memberships by the means of 4.5's Membership associations. This works in particular when several workspaces and user accounts have been created in the pre-4.5 installation.

The Access Control migrations are refactored: the plugin makes no use anymore of both, the postInstall() hook, and the allPluginsActive() listener. These actions performs as migrations now, which makes the control flow and code more clear.

See #592
See #324

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

In 42b11a946a823ed7d04fad5c2fe6544b7c52537b/deepamehta:

Add migration for converting workspaces (#592).

When updating an installation to DM 4.5: all workspaces existing in the pre-4.5 installation get sharing mode "Public". That reflects the pre-4.5 access control semantics. You can change a workspace's sharing mode interactively in the Webclient (or programmatically via API).

3 workspace migrations are consolidated into one.

See #592.

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

In 9fe8b0b2e202c8630ab434f5ef2024355570d9b8/deepamehta:

Fix workspace assignment check (#592).

The check to which workspace an object is assigned to is based on the dm4.workspaces.workspace_id property -- not the Aggregation association. Technical relevant is the property. The association is there just for user benefit (that is visualization).

BREAKING CHANGE

Workspaces API

1 changed method:

boolean isAssignedToWorkspace(long objectId, long workspaceId)

It takes an object ID (that is a topic ID or association ID) as the 1st parameter (formerly a Topic object).
It can also be used to check the assignment of an association.

See #592.

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

In a038bdf4f05ec98c017ba243d43bceab7a179e37/deepamehta:

Migrate workspace assignments (#592).

When upgrading an installation to DM 4.5: workspace assignments are converted into property values. Since 4.5 the workspace assignments are stored as a property. (The Aggregation associations remain there for visualization benefit.)

Note: for a topic/association which has multiple workspace assignments in the pre-4.5 installation NO property value is set. These assignments are considered ambiguous in 4.5. (In 4.5 every topic/association is assigned to exactly ONE workspace.) These objects will not be editable anymore in 4.5. (The multiple Aggregations associations remain there but have no effect.)

The migrations are considered complete now!

You can start testing the upgrade to DM 4.5 now. Just copy your pre-4.5 deepamehta-db folder to the 4.5 installation before starting it. Your content will be migrated to 4.5 automatically. Infos about the conversion process can be seen in the log.

You can upgrade any stable DM release (no snapshots!) that is not older than 4.1.

All your content should be available and editable in 4.5 just like before. In particular all types, topicmaps, user accounts, workspaces, and memberships, should migrate properly. The topicmaps should look like before. All workspaces are transferred as "Public" as this reflects the pre-4.5 access control semantics. Note: some content might vanish from topicmaps, in particular user accounts and usernames as these are not public anymore in 4.5.

Core API

1 new method in class ResultList:

T get(int index)

See #592.

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

In 921a0431f36cedf615012de75983d639c8639bf5/deepamehta:

Workspaces API: make assign calls RESTful (#592).

2 new requests:

PUT /workspace/{workspace_id}/topic/{topic_id}
PUT /workspace/{workspace_id}/association/{assoc_id}

Assigns a topic/association to a workspace.

2 new corresponding REST client methods:

dm4c.restc.assign_topic_to_workspace(topic_id, workspace_id)
dm4c.restc.assign_association_to_workspace(assoc_id, workspace_id)

See #592.

comment:68 follow-up: ↓ 69 Changed 6 years ago by Jörg Richter <jri@…>

In eea039afe0e03b6f821aa7360e27a19fc37b384b/deepamehta:

Add "Assign to Workspace" command (#592).

The topic context menu provides a "Assign to Workspace" command to change the topic's workspace assignment by the means of a dialog box. Basically functional.

Note: changing the workspace assignment affects only the very topic. The assignments of its child topics are not changed.

Issues remain:

  • After assigning the detail panel is not updated immediately.
  • After assigning a stale Aggregation association remain in the map (in case it was revealed before).
  • If a topic has *no* workspace assignment yet this is not reflected by the dialog box's menu selection once opened.

To Do:

  • The dialog box's menu must offer only the workspaces the user has WRITE permission to. Currently all READable workspaces are offered.
  • Also associations need an "Assign to Workspace" command.

See #592.

comment:69 in reply to: ↑ 68 Changed 6 years ago by jri

Replying to Jörg Richter <jri@…>:

Issues remain:

  • After assigning the detail panel is not updated immediately.
  • After assigning a stale Aggregation association remain in the map (in case it was revealed before).
  • If a topic has *no* workspace assignment yet this is not reflected by the dialog box's menu selection once opened.

There are 2 more issues:

  • The assign command must only be available if the user has WRITE permission to the topic.
  • The assign command must not be available for Workspace topics.

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

In 15743bc63298629f0f11256891e55906216287c2/deepamehta:

Workspaces fix: remove assoc on assign (#592).

After assignment the old Aggregation association disappears in case it was visible in the topicmap.

See #592.

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

In cac21905fc59255744d06dd407934c14de73e981/deepamehta:

Workspaces fix: update panel on assign (#592).

After assignment the detail panel shows the new workspace assignment immediately.

See #592.

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

In c9de9946a1620d5e3835c14259378079cefffae1/deepamehta:

Workspaces fix: limit the assign command (#592).

  • The assign command is only available if the user has WRITE permission to the topic.
  • For Workspace topics the assign command is not available .

See #592.

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

In e289686c6dbdf3efa11b3e139026107404e35fb3/deepamehta:

Workspaces fix: limit assignable wrkspaces (#592).

The "Assign Topic to Workspace" dialog box offers only the workspaces the user has WRITE permission to.

See #592.

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

In 10835ef5e4f04ee274c4a27445b17110853fd1fe/deepamehta:

Refactor client-side Workspaces code (#592).

The viewmodel and view code is now fully disentangled.

BREAKING CHANGE

Client-side Workspaces API:

1 renamed method:

get_workspace_id() -> get_selected_workspace_id()

Returns the ID of the selected workspace.

See #592.

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

In b4674a72f3c5d0d019971ded3a2ec958d7f07b79/deepamehta:

Refactor client-side Workspaces code, pt.2 (#592).

See #592.

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

In 83a6200c404919b898c0eb7484cb01ee7053f700/deepamehta:

Add "Assign to Workspace" command to assoc (#592).

Also the association context menu provides a "Assign to Workspace" command.
It changes the association's workspace assignment by the means of a dialog box.

See #592.

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

In 63176507dd132b19140bf6555dd1e1717e5702e4/deepamehta:

Access Control API: generate 401 responses (#592).

When a single object is requested where the caller lacks permission a 401 (Unauthorized) response is generated (instead a generic 500 response).

Note: when an object collection is requested objects where the caller lacks permission are filtered out, possibly resulting in an empty collection. No exception is thrown.

See #592.

comment:78 Changed 6 years ago by jri

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