Ticket #592 (closed Enhancement: fixed)
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:2 Changed 11 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:4 Changed 10 years ago by jri
Finally I'll begin developing this feature now!
Sorry for the delay.
comment:7 Changed 10 years ago by Jörg Richter
comment:8 Changed 10 years ago by Jörg Richter
comment:9 Changed 10 years ago by Jörg Richter
comment:10 Changed 10 years ago by Jörg Richter
comment:11 Changed 10 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 10 years ago by Jörg Richter
comment:13 Changed 10 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.
=> Just want to make sure that we agree on that!?
comment:14 Changed 10 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 10 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 10 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:18 Changed 10 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 10 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 10 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 10 years ago by Jörg Richter
comment:22 Changed 10 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 10 years ago by Jörg Richter
comment:24 Changed 10 years ago by Jörg Richter
comment:26 Changed 10 years ago by Jörg Richter <jri@…>
comment:27 Changed 10 years ago by Jörg Richter <jri@…>
comment:28 Changed 10 years ago by Jörg Richter <jri@…>
comment:29 Changed 10 years ago by Jörg Richter <jri@…>
comment:30 Changed 10 years ago by Jörg Richter <jri@…>
comment:31 Changed 10 years ago by Jörg Richter <jri@…>
comment:32 Changed 10 years ago by Jörg Richter <jri@…>
comment:33 Changed 10 years ago by Jörg Richter <jri@…>
comment:34 Changed 10 years ago by Jörg Richter <jri@…>
comment:35 Changed 10 years ago by Jörg Richter <jri@…>
comment:36 Changed 10 years ago by Jörg Richter <jri@…>
comment:37 Changed 10 years ago by Jörg Richter <jri@…>
comment:38 Changed 10 years ago by jri
For the particular aspect of managing user accounts see also #751
comment:39 Changed 10 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 10 years ago by Jörg Richter <jri@…>
comment:41 Changed 10 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 10 years ago by Jörg Richter <jri@…>
comment:43 Changed 10 years ago by Jörg Richter <jri@…>
comment:44 Changed 10 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 10 years ago by Jörg Richter <jri@…>
comment:46 Changed 10 years ago by Jörg Richter <jri@…>
comment:47 Changed 10 years ago by Jörg Richter <jri@…>
comment:48 Changed 10 years ago by Jörg Richter <jri@…>
comment:49 Changed 10 years ago by Jörg Richter <jri@…>
comment:50 Changed 10 years ago by Jörg Richter <jri@…>
comment:52 Changed 10 years ago by Jörg Richter <jri@…>
comment:53 Changed 10 years ago by Jörg Richter <jri@…>
comment:54 Changed 10 years ago by Jörg Richter <jri@…>
comment:55 Changed 10 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 10 years ago by Jörg Richter <jri@…>
comment:57 Changed 10 years ago by Jörg Richter <jri@…>
comment:58 Changed 10 years ago by Jörg Richter <jri@…>
comment:59 Changed 10 years ago by Jörg Richter <jri@…>
comment:60 Changed 10 years ago by Jörg Richter <jri@…>
comment:61 Changed 10 years ago by Jörg Richter <jri@…>
comment:62 Changed 10 years ago by Jörg Richter <jri@…>
comment:63 Changed 10 years ago by Jörg Richter <jri@…>
comment:64 Changed 10 years ago by Jörg Richter <jri@…>
comment:65 Changed 10 years ago by Jörg Richter <jri@…>
comment:66 Changed 10 years ago by Jörg Richter <jri@…>
comment:67 Changed 10 years ago by Jörg Richter <jri@…>
comment:68 follow-up: ↓ 69 Changed 10 years ago by Jörg Richter <jri@…>
comment:69 in reply to: ↑ 68 Changed 10 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 10 years ago by Jörg Richter <jri@…>
comment:71 Changed 10 years ago by Jörg Richter <jri@…>
comment:72 Changed 10 years ago by Jörg Richter <jri@…>
comment:73 Changed 10 years ago by Jörg Richter <jri@…>
comment:74 Changed 10 years ago by Jörg Richter <jri@…>
comment:75 Changed 10 years ago by Jörg Richter <jri@…>
comment:76 Changed 10 years ago by Jörg Richter <jri@…>
comment:77 Changed 10 years ago by Jörg Richter <jri@…>
comment:78 Changed 10 years ago by jri
- Status changed from accepted to closed
- Resolution set to fixed
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:
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.