Access Control

[jri]

As a start DM3's Access Control module should be ported to DM4.
Its conceptualization is as follows:

Every topic (and thus every type) is attached by 3 things:

• an Access Control List (ACL). Its entries define weather an operation is allowed for a user role.
• a creator: the user who created the topic.
• an owner: the user who owned the topic.

2 operations are supported:

• write: change the topic
• create: create an instance. Applies to types only.

More operations might be added in the future.
Note: for the moment "read" is always allowed. There are no private topics.

4 roles are supported:

• everyone: applies to every internet user
• member: applies to all members of each workspace the topic's type is assigned to
• owner: applies to the topic owner
• creator: applies to the topic creator

More roles might be added in the future.

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.7 (#262)

Porting proceeds.
Login works.
Not yet funtional.

See ticket 262.

• Changeset: 54fcd760bde0350ee108470eb268319aff04d857
• URL: ​https://github.com/jri/deepamehta/commit/54fcd760bde0350ee108470eb268319aff04d857

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.8 (#262)

Logout works.
Not yet usable.

See ticket 262.

• Changeset: 6f81e01f5e8529d39ca9411b09e4f223e5489b67
• URL: ​https://github.com/jri/deepamehta/commit/6f81e01f5e8529d39ca9411b09e4f223e5489b67

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.9 (#262)

Create ACL entries.
Not yet usable.

See ticket 262.

• Changeset: edee1c99fe3373012718c393fde01f27a3b26f8c
• URL: ​https://github.com/jri/deepamehta/commit/edee1c99fe3373012718c393fde01f27a3b26f8c

[Jörg Richter]

Access Control: port from DM3 to DM4, Pt.10 (#262)

Fix ref updates in ACL entry, creator, and owner.
Not yet usable.

See ticket 262.

• Changeset: 54dc8bca4c8afb5931173f12af46c25142ca8b64
• URL: ​https://github.com/jri/deepamehta/commit/54dc8bca4c8afb5931173f12af46c25142ca8b64

[Jörg Richter]

Access Control: change model (#262).

The Creator and Owner facets reference a Username (instead a User Account)

Not yet usable.

See ticket 262.

• Changeset: fff60e353521f3b2f4954a51207f71b3fe616311
• URL: ​https://github.com/jri/deepamehta/commit/fff60e353521f3b2f4954a51207f71b3fe616311

[Jörg Richter]

Access Control: functional for the time (#262).

Types are attached with ACLs.
Logged in users can create and edit topics.
Anonymous can't edit topics.

So, basic functionality is there for the first time.
A lot of issues remain.

See ticket 262.

• Changeset: ad357c93bf71c7d41dd48ce868d3620b4d1d9b47
• URL: ​https://github.com/jri/deepamehta/commit/ad357c93bf71c7d41dd48ce868d3620b4d1d9b47

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.7 (#262)

Porting proceeds.
Login works.
Not yet funtional.

See ticket 262.

• Changeset: 54fcd760bde0350ee108470eb268319aff04d857
• URL: ​https://github.com/jri/deepamehta/commit/54fcd760bde0350ee108470eb268319aff04d857

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.8 (#262)

Logout works.
Not yet usable.

See ticket 262.

• Changeset: 6f81e01f5e8529d39ca9411b09e4f223e5489b67
• URL: ​https://github.com/jri/deepamehta/commit/6f81e01f5e8529d39ca9411b09e4f223e5489b67

[Jörg Richter]

Access Control: adapt from DM3 to DM4, Pt.9 (#262)

Create ACL entries.
Not yet usable.

See ticket 262.

• Changeset: edee1c99fe3373012718c393fde01f27a3b26f8c
• URL: ​https://github.com/jri/deepamehta/commit/edee1c99fe3373012718c393fde01f27a3b26f8c

[Jörg Richter]

Access Control: port from DM3 to DM4, Pt.10 (#262)

Fix ref updates in ACL entry, creator, and owner.
Not yet usable.

See ticket 262.

• Changeset: 54dc8bca4c8afb5931173f12af46c25142ca8b64
• URL: ​https://github.com/jri/deepamehta/commit/54dc8bca4c8afb5931173f12af46c25142ca8b64

[Jörg Richter]

Access Control: change model (#262).

The Creator and Owner facets reference a Username (instead a User Account)

Not yet usable.

See ticket 262.

• Changeset: fff60e353521f3b2f4954a51207f71b3fe616311
• URL: ​https://github.com/jri/deepamehta/commit/fff60e353521f3b2f4954a51207f71b3fe616311

[Jörg Richter]

Access Control: functional for the time (#262).

Types are attached with ACLs.
Logged in users can create and edit topics.
Anonymous can't edit topics.

So, basic functionality is there for the first time.
A lot of issues remain.

See ticket 262.

• Changeset: ad357c93bf71c7d41dd48ce868d3620b4d1d9b47
• URL: ​https://github.com/jri/deepamehta/commit/ad357c93bf71c7d41dd48ce868d3620b4d1d9b47

[Jörg Richter]

Extend Access Control service (#262).

New service method:

Permissions getTopicPermissions(long topicId, ClientState? clientState)

REST API:

GET /accesscontrol/topic/{topic_id}

See ticket 262.

• Changeset: 453494423a809f91aa1c5a6d8a8428c386ba1aaa
• URL: ​https://github.com/jri/deepamehta/commit/453494423a809f91aa1c5a6d8a8428c386ba1aaa

[Jörg Richter]

Access Control: adapt to recent core changes #262.

Functionality is restored.

See ticket 262

• Changeset: d98e2ba94f46f2d4297699f2131799b13113454a
• URL: ​https://github.com/jri/deepamehta/commit/d98e2ba94f46f2d4297699f2131799b13113454a

[Jörg Richter]

Access Control: fix login dialog (#262).

Adapted to recent changes in GUIToolkit's Dialog class.

Furthermore in GUIToolkit: the Dialog's close() method takes 2 optional parameters to run a fade out animation:

    dialog.close(duration, callback)

Furthermore in Webclient: there is a new GUI helper method to attach a Return key handler to an jQuery object:

    dm4c.on_return_key(element, callback)

See ticket 262.

• Changeset: 0d66742648da6fe36c8de12bdb2b18d35652cdd6
• URL: ​https://github.com/jri/deepamehta/commit/0d66742648da6fe36c8de12bdb2b18d35652cdd6

[Jörg Richter]

Access Control: new call require_login() (#262).

3rd-party plugins can require the user to login before she can do anything.
This allows DM installations to be accessible only by authentified users.
To do so call require_login() from your plugin's init handler:

    dm4c.add_listener("init", function() {
        dm4c.get_plugin("de.deepamehta.accesscontrol").require_login()
        ...
    }

This brings up the Login dialog while Webclient start.
This Login dialog can't be closed by the user.

However, the Login dialog does *not* appear if the user is still logged in (there is a cookie) while Webclient start.
In this case she can continue work immediately.

Furthermore in GUIToolkit: the Dialog's open() method takes one optional boolean parameter:

    dialog.open(no_close_button)

If no_close_button is true the dialog box will neither have a close button nor react on the ESC key.

See ticket 262.

• Changeset: b9ec721888b15e465d7e2e7cf24ae9241025fc89
• URL: ​https://github.com/jri/deepamehta/commit/b9ec721888b15e465d7e2e7cf24ae9241025fc89

[Jörg Richter]

Access Control: polish CSS (#262).

Generic CSS moved from Access Control to Webclient module.

See ticket 262.

• Changeset: 164ad8caf317d375f130dc029c912a7693c412a2
• URL: ​https://github.com/jri/deepamehta/commit/164ad8caf317d375f130dc029c912a7693c412a2

[Jörg Richter]

Access Control: new role USER (#262).

There is a 5th role: a USER represents everyone who is logged in.
The USER role can be used in ACL entries just like the other roles.

This allows development of closed user group applications without the complexity of the MEMBER role and without the requirement of the Workspaces module to be installed.

See ticket 262.

• Changeset: 2892c96c44ff16056520fa165ec9344cde5cd29c
• URL: ​https://github.com/jri/deepamehta/commit/2892c96c44ff16056520fa165ec9344cde5cd29c

[Jörg Richter]

Access Control: fix startup without DB (#262).

See ticket 262.

• Changeset: 2ac6bb29a813d1c64021f0a3aede765eec8f7407
• URL: ​https://github.com/jri/deepamehta/commit/2ac6bb29a813d1c64021f0a3aede765eec8f7407

[Jörg Richter]

Access Control for associations, pt.1 (#262).

3 new core events:

• PRE_CREATE_ASSOCIATION
• POST_CREATE_ASSOCIATION
• PRE_SEND_ASSOCIATION

Access Control API:

• createACLEntry() takes a DeepaMehtaObject? (instead a Topic)

Facets API:

• getFacet() takes a DeepaMehtaObject? (instead a Topic)
• getFacets() takes a DeepaMehtaObject? (instead a Topic)
• updateFacet() takes a DeepaMehtaObject? (instead a Topic)
• updateFacets() takes a DeepaMehtaObject? (instead a Topic)

Client-side events:

• "has_write_permission_for_topic" replaces "has_write_permission"
• "has_write_permission_for_association" is new

Webclient API:

• dm4c.has_write_permission_for_topic() replaces dm4c.has_write_permission()
• dm4c.has_write_permission_for_association() is new

IMPORTANT: if your plugin uses dm4c.has_write_permission() it must be adapted

The "assoc-acl" branch is not yet functional. Do not install it.

See ticket 262.

• Changeset: 98fb628d3ae11efeef9b03963309dcc41a31003e
• URL: ​https://github.com/jri/deepamehta/commit/98fb628d3ae11efeef9b03963309dcc41a31003e

[Jörg Richter]

Access Control for associations, pt.2 (#262).

Basically functional.

"Role" wording globally changed to "User Role" to avoid a name clash.
Class "Role" exists already in de.deepamehta.core.Role

• class renamed de.deepamehta.plugins.accesscontrol.model.Role -> UserRole?
• topic type renamed "Role" -> "User Role"
• type URI renamed "dm4.accesscontrol.role" -> "dm4.accesscontrol.user_role"
• instance URIs renamed:
  • "dm4.accesscontrol.role_creator" -> "dm4.accesscontrol.user_role.creator"
  • "dm4.accesscontrol.role_owner" -> "dm4.accesscontrol.user_role.owner"
  • "dm4.accesscontrol.role_member" -> "dm4.accesscontrol.user_role.member"
  • "dm4.accesscontrol.role_user" -> "dm4.accesscontrol.user_role.user"
  • "dm4.accesscontrol.role_everyone" -> "dm4.accesscontrol.user_role.everyone"

Operation instance URIs renamed:

• "dm4.accesscontrol.operation_write" -> "dm4.accesscontrol.operation.write"
• "dm4.accesscontrol.operation_create" -> "dm4.accesscontrol.operation.create"

IMPORTANT: for production installations the admin must supply a migration to update the changed URIs accordingly.
IMPORTANT: for testing installations the DB must be reset.

Furthermore in Core:

• TopicRole? interface has new getTopic() method

See ticket 262.

• Changeset: 1caba884a4a4691c3dc2eeaf56f0397a635ae37c
• URL: ​https://github.com/jri/deepamehta/commit/1caba884a4a4691c3dc2eeaf56f0397a635ae37c

[Jörg Richter]

Access Control for associations, pt.1 (#262).

3 new core events:

• PRE_CREATE_ASSOCIATION
• POST_CREATE_ASSOCIATION
• PRE_SEND_ASSOCIATION

Access Control API:

• createACLEntry() takes a DeepaMehtaObject? (instead a Topic)

Facets API:

• getFacet() takes a DeepaMehtaObject? (instead a Topic)
• getFacets() takes a DeepaMehtaObject? (instead a Topic)
• updateFacet() takes a DeepaMehtaObject? (instead a Topic)
• updateFacets() takes a DeepaMehtaObject? (instead a Topic)

Client-side events:

• "has_write_permission_for_topic" replaces "has_write_permission"
• "has_write_permission_for_association" is new

Webclient API:

• dm4c.has_write_permission_for_topic() replaces dm4c.has_write_permission()
• dm4c.has_write_permission_for_association() is new

IMPORTANT: if your plugin uses dm4c.has_write_permission() it must be adapted

The "assoc-acl" branch is not yet functional. Do not install it.

See ticket 262.

• Changeset: 98fb628d3ae11efeef9b03963309dcc41a31003e
• URL: ​https://github.com/jri/deepamehta/commit/98fb628d3ae11efeef9b03963309dcc41a31003e

[Jörg Richter]

Access Control for associations, pt.2 (#262).

Basically functional.

"Role" wording globally changed to "User Role" to avoid a name clash.
Class "Role" exists already in de.deepamehta.core.Role

• class renamed de.deepamehta.plugins.accesscontrol.model.Role -> UserRole?
• topic type renamed "Role" -> "User Role"
• type URI renamed "dm4.accesscontrol.role" -> "dm4.accesscontrol.user_role"
• instance URIs renamed:
  • "dm4.accesscontrol.role_creator" -> "dm4.accesscontrol.user_role.creator"
  • "dm4.accesscontrol.role_owner" -> "dm4.accesscontrol.user_role.owner"
  • "dm4.accesscontrol.role_member" -> "dm4.accesscontrol.user_role.member"
  • "dm4.accesscontrol.role_user" -> "dm4.accesscontrol.user_role.user"
  • "dm4.accesscontrol.role_everyone" -> "dm4.accesscontrol.user_role.everyone"

Operation instance URIs renamed:

• "dm4.accesscontrol.operation_write" -> "dm4.accesscontrol.operation.write"
• "dm4.accesscontrol.operation_create" -> "dm4.accesscontrol.operation.create"

IMPORTANT: for production installations the admin must supply a migration to update the changed URIs accordingly.
IMPORTANT: for testing installations the DB must be reset.

Furthermore in Core:

• TopicRole? interface has new getTopic() method

See ticket 262.

• Changeset: 1caba884a4a4691c3dc2eeaf56f0397a635ae37c
• URL: ​https://github.com/jri/deepamehta/commit/1caba884a4a4691c3dc2eeaf56f0397a635ae37c

[Jörg Richter]

Access Control: create account via GUI (#262).

The Create menu provides a "New User Account" item.
However, newly created users have no permission to create anything yet.

Furthermore in Webclient:

• new client-side hook "pre_update_topic"

Furthermore in Core:

• JerseyResponseFilter?'s exception log is improved

See ticket 262.

• Changeset: c49d6ee120d7e1ee32653949daec061d80b1856e
• URL: ​https://github.com/jri/deepamehta/commit/c49d6ee120d7e1ee32653949daec061d80b1856e

[Jörg Richter]

Revise Workspaces model and API (#262).

Workspace assignments are facets (as provided by the Facets plugin).
The Workspaces API is reshaped to be more generic. Workspaces can be assigned to associations as well.
There are just 3 methods:

Topic createWorkspace(String name)

void assignWorkspace(DeepaMehtaObject object, long workspaceId)

Set<RelatedTopic> getAssignedWorkspaces(DeepaMehtaObject object)

The Workspaces data model has changed:

• Drop association type "Workspace Context" ("dm4.workspaces.workspace_context")
• Drop role type "Workspace Topic" ("dm4.workspaces.workspace_topic")
• Drop role type "Workspace Type" ("dm4.workspaces.workspace_type")

Old:

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Topic
        role type "Default"                         role type "Workspace Topic"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_topic")

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Type
        role type "Default"                         role type "Workspace Type"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_type")

New:

                   association type "Aggregation"
    Workspace <------ ("dm4.core.aggregation") ------> DeepaMehtaObject (Topic, Type, ..)
        role type "Part"                                   role type "Whole"
        ("dm4.core.part")                                  ("dm4.core.whole")

In the new model a workspace assignment is a core aggregation ("Many").
The workspace is a facet ("Part") of the object ("Whole").
There is no distinction between Topic or Type objects.

IMPORTANT: for production installations the admin must provide a
migration to convert the workspace assignments to the new model.
For test installations the DB must be reset.

In preparation for the MEMBER user role of the Access Control plugin.

See ticket 262.

• Changeset: 36dfe0e16032c26115e6cddbebb8f98b97e0da42
• URL: ​https://github.com/jri/deepamehta/commit/36dfe0e16032c26115e6cddbebb8f98b97e0da42

[Jörg Richter]

Access Control: assign types to workspace (#262).

The topic types of the DeepaMehta Standard Distribution are assignedd to the default workspace.
The default workspace is now called "DeepaMehta" (formerly "Default").

In preparation for the MEMBER user role of the Access Control plugin.

Fix: searching for a workspace by name finds the workspace (instead of all the topics assigned to it).

Furthermore in Core:
The pseudo-type "Meta Meta Type" ("dm4.core.meta_meta_type") is not introduced to plugins.

See ticket 262.

• Changeset: e11334109df7a1ad50bf42428d59aa9e31e94a8b
• URL: ​https://github.com/jri/deepamehta/commit/e11334109df7a1ad50bf42428d59aa9e31e94a8b

[Jörg Richter]

Access Control: MEMBER is ACL default role (#262).

A topic can be edited by the members of all workspaces the topic is assigned to.
Topics can be created by the members of all workspaces the respective type is assigned to.

The default user ("admin") is assigned to default workspace ("DeepaMehta").
New users are assigned to the current workspace by default (not yet functional).

Thus, collaboration with equal permissions within workspace borders is the default setup.

ACL model change:
The association type "Membership" (dm4.accesscontrol.membership) is dropped.
Instead the Username topic's regular workspace assignment is interpreted as a membership.

Facets API:

• hasFacet() is a new method

Workspaces API:

• isAssignedToWorkspace() is a new method
• getDefaultWorkspace() is a new method

Workspaces fix:

• updating workspace assignment works

See ticket 262.

• Changeset: 785e1a93b930e6e04dd7fede678653dacea26596
• URL: ​https://github.com/jri/deepamehta/commit/785e1a93b930e6e04dd7fede678653dacea26596

[Jörg Richter]

Access Control: fix user account creation (#262).

New users are assigned to the current workspace, and thus get proper permissions.
New user accounts are functional.

IMPORTANT for plugin developers: when calling dms.createTopic() make sure to pass the ClientState?.
Otherwise the new topic get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 424431c2665b1588b3cafdb6a96370699cacbfd3
• URL: ​https://github.com/jri/deepamehta/commit/424431c2665b1588b3cafdb6a96370699cacbfd3

[Jörg Richter]

Fix Access Control for default topicmap (#262).

The default topicmap is guaranteed to have a) an workspace assignment, b) an ACL entry, and c) a creator information.

See ticket 262.

• Changeset: 4553116d4a9eff3816ebbf3292f11eb0dc9a185a
• URL: ​https://github.com/jri/deepamehta/commit/4553116d4a9eff3816ebbf3292f11eb0dc9a185a

[Jörg Richter]

Setup associations for Access Control (#262).

New associations are assigned to the current workspace, and thus are properly setup for access control.

IMPORTANT for plugin developers: when calling dms.createAssociation() make sure to pass the ClientState?.
Otherwise the new association get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c
• URL: ​https://github.com/jri/deepamehta/commit/84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c

[Jörg Richter]

Revise Workspaces model and API (#262).

Workspace assignments are facets (as provided by the Facets plugin).
The Workspaces API is reshaped to be more generic. Workspaces can be assigned to associations as well.
There are just 3 methods:

Topic createWorkspace(String name)

void assignWorkspace(DeepaMehtaObject object, long workspaceId)

Set<RelatedTopic> getAssignedWorkspaces(DeepaMehtaObject object)

The Workspaces data model has changed:

• Drop association type "Workspace Context" ("dm4.workspaces.workspace_context")
• Drop role type "Workspace Topic" ("dm4.workspaces.workspace_topic")
• Drop role type "Workspace Type" ("dm4.workspaces.workspace_type")

Old:

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Topic
        role type "Default"                         role type "Workspace Topic"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_topic")

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Type
        role type "Default"                         role type "Workspace Type"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_type")

New:

                   association type "Aggregation"
    Workspace <------ ("dm4.core.aggregation") ------> DeepaMehtaObject (Topic, Type, ..)
        role type "Part"                                   role type "Whole"
        ("dm4.core.part")                                  ("dm4.core.whole")

In the new model a workspace assignment is a core aggregation ("Many").
The workspace is a facet ("Part") of the object ("Whole").
There is no distinction between Topic or Type objects.

IMPORTANT: for production installations the admin must provide a
migration to convert the workspace assignments to the new model.
For test installations the DB must be reset.

In preparation for the MEMBER user role of the Access Control plugin.

See ticket 262.

• Changeset: 36dfe0e16032c26115e6cddbebb8f98b97e0da42
• URL: ​https://github.com/jri/deepamehta/commit/36dfe0e16032c26115e6cddbebb8f98b97e0da42

[Jörg Richter]

Access Control: assign types to workspace (#262).

The topic types of the DeepaMehta Standard Distribution are assignedd to the default workspace.
The default workspace is now called "DeepaMehta" (formerly "Default").

In preparation for the MEMBER user role of the Access Control plugin.

Fix: searching for a workspace by name finds the workspace (instead of all the topics assigned to it).

Furthermore in Core:
The pseudo-type "Meta Meta Type" ("dm4.core.meta_meta_type") is not introduced to plugins.

See ticket 262.

• Changeset: e11334109df7a1ad50bf42428d59aa9e31e94a8b
• URL: ​https://github.com/jri/deepamehta/commit/e11334109df7a1ad50bf42428d59aa9e31e94a8b

[Jörg Richter]

Access Control: MEMBER is ACL default role (#262).

A topic can be edited by the members of all workspaces the topic is assigned to.
Topics can be created by the members of all workspaces the respective type is assigned to.

The default user ("admin") is assigned to default workspace ("DeepaMehta").
New users are assigned to the current workspace by default (not yet functional).

Thus, collaboration with equal permissions within workspace borders is the default setup.

ACL model change:
The association type "Membership" (dm4.accesscontrol.membership) is dropped.
Instead the Username topic's regular workspace assignment is interpreted as a membership.

Facets API:

• hasFacet() is a new method

Workspaces API:

• isAssignedToWorkspace() is a new method
• getDefaultWorkspace() is a new method

Workspaces fix:

• updating workspace assignment works

See ticket 262.

• Changeset: 785e1a93b930e6e04dd7fede678653dacea26596
• URL: ​https://github.com/jri/deepamehta/commit/785e1a93b930e6e04dd7fede678653dacea26596

[Jörg Richter]

Access Control: fix user account creation (#262).

New users are assigned to the current workspace, and thus get proper permissions.
New user accounts are functional.

IMPORTANT for plugin developers: when calling dms.createTopic() make sure to pass the ClientState?.
Otherwise the new topic get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 424431c2665b1588b3cafdb6a96370699cacbfd3
• URL: ​https://github.com/jri/deepamehta/commit/424431c2665b1588b3cafdb6a96370699cacbfd3

[Jörg Richter]

Fix Access Control for default topicmap (#262).

The default topicmap is guaranteed to have a) an workspace assignment, b) an ACL entry, and c) a creator information.

See ticket 262.

• Changeset: 4553116d4a9eff3816ebbf3292f11eb0dc9a185a
• URL: ​https://github.com/jri/deepamehta/commit/4553116d4a9eff3816ebbf3292f11eb0dc9a185a

[Jörg Richter]

Setup associations for Access Control (#262).

New associations are assigned to the current workspace, and thus are properly setup for access control.

IMPORTANT for plugin developers: when calling dms.createAssociation() make sure to pass the ClientState?.
Otherwise the new association get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c
• URL: ​https://github.com/jri/deepamehta/commit/84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c

[Jörg Richter]

Extend Access Control service (#262).

New service method:

Permissions getTopicPermissions(long topicId, ClientState? clientState)

REST API:

GET /accesscontrol/topic/{topic_id}

See ticket 262.

• Changeset: 453494423a809f91aa1c5a6d8a8428c386ba1aaa
• URL: ​https://github.com/jri/deepamehta/commit/453494423a809f91aa1c5a6d8a8428c386ba1aaa

[Jörg Richter]

Access Control: adapt to recent core changes #262.

Functionality is restored.

See ticket 262

• Changeset: d98e2ba94f46f2d4297699f2131799b13113454a
• URL: ​https://github.com/jri/deepamehta/commit/d98e2ba94f46f2d4297699f2131799b13113454a

[Jörg Richter]

Access Control: fix login dialog (#262).

Adapted to recent changes in GUIToolkit's Dialog class.

Furthermore in GUIToolkit: the Dialog's close() method takes 2 optional parameters to run a fade out animation:

    dialog.close(duration, callback)

Furthermore in Webclient: there is a new GUI helper method to attach a Return key handler to an jQuery object:

    dm4c.on_return_key(element, callback)

See ticket 262.

• Changeset: 0d66742648da6fe36c8de12bdb2b18d35652cdd6
• URL: ​https://github.com/jri/deepamehta/commit/0d66742648da6fe36c8de12bdb2b18d35652cdd6

[Jörg Richter]

Access Control: new call require_login() (#262).

3rd-party plugins can require the user to login before she can do anything.
This allows DM installations to be accessible only by authentified users.
To do so call require_login() from your plugin's init handler:

    dm4c.add_listener("init", function() {
        dm4c.get_plugin("de.deepamehta.accesscontrol").require_login()
        ...
    }

This brings up the Login dialog while Webclient start.
This Login dialog can't be closed by the user.

However, the Login dialog does *not* appear if the user is still logged in (there is a cookie) while Webclient start.
In this case she can continue work immediately.

Furthermore in GUIToolkit: the Dialog's open() method takes one optional boolean parameter:

    dialog.open(no_close_button)

If no_close_button is true the dialog box will neither have a close button nor react on the ESC key.

See ticket 262.

• Changeset: b9ec721888b15e465d7e2e7cf24ae9241025fc89
• URL: ​https://github.com/jri/deepamehta/commit/b9ec721888b15e465d7e2e7cf24ae9241025fc89

[Jörg Richter]

Access Control: polish CSS (#262).

Generic CSS moved from Access Control to Webclient module.

See ticket 262.

• Changeset: 164ad8caf317d375f130dc029c912a7693c412a2
• URL: ​https://github.com/jri/deepamehta/commit/164ad8caf317d375f130dc029c912a7693c412a2

[Jörg Richter]

Access Control: new role USER (#262).

There is a 5th role: a USER represents everyone who is logged in.
The USER role can be used in ACL entries just like the other roles.

This allows development of closed user group applications without the complexity of the MEMBER role and without the requirement of the Workspaces module to be installed.

See ticket 262.

• Changeset: 2892c96c44ff16056520fa165ec9344cde5cd29c
• URL: ​https://github.com/jri/deepamehta/commit/2892c96c44ff16056520fa165ec9344cde5cd29c

[Jörg Richter]

Access Control: fix startup without DB (#262).

See ticket 262.

• Changeset: 2ac6bb29a813d1c64021f0a3aede765eec8f7407
• URL: ​https://github.com/jri/deepamehta/commit/2ac6bb29a813d1c64021f0a3aede765eec8f7407

[Jörg Richter]

Access Control for associations, pt.1 (#262).

3 new core events:

• PRE_CREATE_ASSOCIATION
• POST_CREATE_ASSOCIATION
• PRE_SEND_ASSOCIATION

Access Control API:

• createACLEntry() takes a DeepaMehtaObject? (instead a Topic)

Facets API:

• getFacet() takes a DeepaMehtaObject? (instead a Topic)
• getFacets() takes a DeepaMehtaObject? (instead a Topic)
• updateFacet() takes a DeepaMehtaObject? (instead a Topic)
• updateFacets() takes a DeepaMehtaObject? (instead a Topic)

Client-side events:

• "has_write_permission_for_topic" replaces "has_write_permission"
• "has_write_permission_for_association" is new

Webclient API:

• dm4c.has_write_permission_for_topic() replaces dm4c.has_write_permission()
• dm4c.has_write_permission_for_association() is new

IMPORTANT: if your plugin uses dm4c.has_write_permission() it must be adapted

The "assoc-acl" branch is not yet functional. Do not install it.

See ticket 262.

• Changeset: 98fb628d3ae11efeef9b03963309dcc41a31003e
• URL: ​https://github.com/jri/deepamehta/commit/98fb628d3ae11efeef9b03963309dcc41a31003e

[Jörg Richter]

Access Control for associations, pt.2 (#262).

Basically functional.

"Role" wording globally changed to "User Role" to avoid a name clash.
Class "Role" exists already in de.deepamehta.core.Role

• class renamed de.deepamehta.plugins.accesscontrol.model.Role -> UserRole?
• topic type renamed "Role" -> "User Role"
• type URI renamed "dm4.accesscontrol.role" -> "dm4.accesscontrol.user_role"
• instance URIs renamed:
  • "dm4.accesscontrol.role_creator" -> "dm4.accesscontrol.user_role.creator"
  • "dm4.accesscontrol.role_owner" -> "dm4.accesscontrol.user_role.owner"
  • "dm4.accesscontrol.role_member" -> "dm4.accesscontrol.user_role.member"
  • "dm4.accesscontrol.role_user" -> "dm4.accesscontrol.user_role.user"
  • "dm4.accesscontrol.role_everyone" -> "dm4.accesscontrol.user_role.everyone"

Operation instance URIs renamed:

• "dm4.accesscontrol.operation_write" -> "dm4.accesscontrol.operation.write"
• "dm4.accesscontrol.operation_create" -> "dm4.accesscontrol.operation.create"

IMPORTANT: for production installations the admin must supply a migration to update the changed URIs accordingly.
IMPORTANT: for testing installations the DB must be reset.

Furthermore in Core:

• TopicRole? interface has new getTopic() method

See ticket 262.

• Changeset: 1caba884a4a4691c3dc2eeaf56f0397a635ae37c
• URL: ​https://github.com/jri/deepamehta/commit/1caba884a4a4691c3dc2eeaf56f0397a635ae37c

[Jörg Richter]

Access Control: create account via GUI (#262).

The Create menu provides a "New User Account" item.
However, newly created users have no permission to create anything yet.

Furthermore in Webclient:

• new client-side hook "pre_update_topic"

Furthermore in Core:

• JerseyResponseFilter?'s exception log is improved

See ticket 262.

• Changeset: c49d6ee120d7e1ee32653949daec061d80b1856e
• URL: ​https://github.com/jri/deepamehta/commit/c49d6ee120d7e1ee32653949daec061d80b1856e

[Jörg Richter]

Revise Workspaces model and API (#262).

Workspace assignments are facets (as provided by the Facets plugin).
The Workspaces API is reshaped to be more generic. Workspaces can be assigned to associations as well.
There are just 3 methods:

Topic createWorkspace(String name)

void assignWorkspace(DeepaMehtaObject object, long workspaceId)

Set<RelatedTopic> getAssignedWorkspaces(DeepaMehtaObject object)

The Workspaces data model has changed:

• Drop association type "Workspace Context" ("dm4.workspaces.workspace_context")
• Drop role type "Workspace Topic" ("dm4.workspaces.workspace_topic")
• Drop role type "Workspace Type" ("dm4.workspaces.workspace_type")

Old:

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Topic
        role type "Default"                         role type "Workspace Topic"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_topic")

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Type
        role type "Default"                         role type "Workspace Type"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_type")

New:

                   association type "Aggregation"
    Workspace <------ ("dm4.core.aggregation") ------> DeepaMehtaObject (Topic, Type, ..)
        role type "Part"                                   role type "Whole"
        ("dm4.core.part")                                  ("dm4.core.whole")

In the new model a workspace assignment is a core aggregation ("Many").
The workspace is a facet ("Part") of the object ("Whole").
There is no distinction between Topic or Type objects.

IMPORTANT: for production installations the admin must provide a
migration to convert the workspace assignments to the new model.
For test installations the DB must be reset.

In preparation for the MEMBER user role of the Access Control plugin.

See ticket 262.

• Changeset: 36dfe0e16032c26115e6cddbebb8f98b97e0da42
• URL: ​https://github.com/jri/deepamehta/commit/36dfe0e16032c26115e6cddbebb8f98b97e0da42

[Jörg Richter]

Access Control: assign types to workspace (#262).

The topic types of the DeepaMehta Standard Distribution are assignedd to the default workspace.
The default workspace is now called "DeepaMehta" (formerly "Default").

In preparation for the MEMBER user role of the Access Control plugin.

Fix: searching for a workspace by name finds the workspace (instead of all the topics assigned to it).

Furthermore in Core:
The pseudo-type "Meta Meta Type" ("dm4.core.meta_meta_type") is not introduced to plugins.

See ticket 262.

• Changeset: e11334109df7a1ad50bf42428d59aa9e31e94a8b
• URL: ​https://github.com/jri/deepamehta/commit/e11334109df7a1ad50bf42428d59aa9e31e94a8b

[Jörg Richter]

Access Control: MEMBER is ACL default role (#262).

A topic can be edited by the members of all workspaces the topic is assigned to.
Topics can be created by the members of all workspaces the respective type is assigned to.

The default user ("admin") is assigned to default workspace ("DeepaMehta").
New users are assigned to the current workspace by default (not yet functional).

Thus, collaboration with equal permissions within workspace borders is the default setup.

ACL model change:
The association type "Membership" (dm4.accesscontrol.membership) is dropped.
Instead the Username topic's regular workspace assignment is interpreted as a membership.

Facets API:

• hasFacet() is a new method

Workspaces API:

• isAssignedToWorkspace() is a new method
• getDefaultWorkspace() is a new method

Workspaces fix:

• updating workspace assignment works

See ticket 262.

• Changeset: 785e1a93b930e6e04dd7fede678653dacea26596
• URL: ​https://github.com/jri/deepamehta/commit/785e1a93b930e6e04dd7fede678653dacea26596

[Jörg Richter]

Access Control: fix user account creation (#262).

New users are assigned to the current workspace, and thus get proper permissions.
New user accounts are functional.

IMPORTANT for plugin developers: when calling dms.createTopic() make sure to pass the ClientState?.
Otherwise the new topic get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 424431c2665b1588b3cafdb6a96370699cacbfd3
• URL: ​https://github.com/jri/deepamehta/commit/424431c2665b1588b3cafdb6a96370699cacbfd3

[Jörg Richter]

Fix Access Control for default topicmap (#262).

The default topicmap is guaranteed to have a) an workspace assignment, b) an ACL entry, and c) a creator information.

See ticket 262.

• Changeset: 4553116d4a9eff3816ebbf3292f11eb0dc9a185a
• URL: ​https://github.com/jri/deepamehta/commit/4553116d4a9eff3816ebbf3292f11eb0dc9a185a

[Jörg Richter]

Setup associations for Access Control (#262).

New associations are assigned to the current workspace, and thus are properly setup for access control.

IMPORTANT for plugin developers: when calling dms.createAssociation() make sure to pass the ClientState?.
Otherwise the new association get no workspace assignment, and thus will not be editable by default.

See ticket 262.

• Changeset: 84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c
• URL: ​https://github.com/jri/deepamehta/commit/84ed1a5a29b5a1c51b7fa9a503721d9a22f02f7c

[Jörg Richter]

Extend Access Control API (#262).

AccessControlService?:

• void setCreator(DeepaMehtaObject? object, long usernameId) is a new method.
• Topic getCreator(DeepaMehtaObject? object) is a new method.
• Topic getOwner(DeepaMehtaObject? object) is a new method.
• Topic getUsername(String username) is a new method.
• DEFAULT_USERNAME is a public constant ("admin").
• getOwnedTopic() is removed.

Permissions:

• add() returns the Permissions object

The Access Control startup activity has changed: for topics and associations created by migrations NO creator and
NO access control entries are set. Because of the undeterministic plugin startup order it would be undeterministic
which topics and associations get these assignments and which one do not.

Instead it's up the plugins which create topic and asssociation instances in migrations to setup the creator and
access control entries. (this is now identical to the Workspace assignment behavoir.)

See ticket 262.

• Changeset: 889552e36e3542afb060b8bfd285a5d7af88420e
• URL: ​https://github.com/jri/deepamehta/commit/889552e36e3542afb060b8bfd285a5d7af88420e

[Jörg Richter]

Fix: new topicmaps get workspace assignment (#262)

See ticket 262.

• Changeset: 8d375a2a6ef87ca101aa263115b94fa15012aca3
• URL: ​https://github.com/jri/deepamehta/commit/8d375a2a6ef87ca101aa263115b94fa15012aca3

[Jörg Richter]

Access Control can be switched off (#262).

Access Control works as an optional plugin.
DeepaMehta works fine if the Access Control plugin is deactivated.
This is intended for single-place (non-networked) installations.

See ticket 262.

• Changeset: e19fabbace55572be3427fc11c639616d0bfcb6c
• URL: ​https://github.com/jri/deepamehta/commit/e19fabbace55572be3427fc11c639616d0bfcb6c

[Jörg Richter]

Access Control: workspace creator joins (#262).

The creator of a workspace joins that workspace automatically.

Thanks Malte for noticing!

See ticket 262.

• Changeset: 1b7264a92666e8fd6354c7884e3664b44453e929
• URL: ​https://github.com/jri/deepamehta/commit/1b7264a92666e8fd6354c7884e3664b44453e929

[Jörg Richter]

Access Control: fix join workspace (#262).

See ticket 262.

• Changeset: 96173ddb1b6cf579d21bce8ea3e145067dfbd7b8
• URL: ​https://github.com/jri/deepamehta/commit/96173ddb1b6cf579d21bce8ea3e145067dfbd7b8

[jri]

The original concept is realized. Model and API seem complete for the moment. However, 2 crucial things remain to do:
1) Make ACLs, Ownerships, Workspace Memberships etc. configurable via GUI.
2) Replace low-level storage of ACLs etc. We want store these information *outside* the graph. That is, not as topics but as Neo4j properties.
These aspects will be addressed in separate tickets.