Changes between Version 9 and Version 10 of Malted/PluginDevelopmentNotes

Timestamp:

13.01.2014 14:09:25 (11 years ago)

Author:

Malte

Comment:

some corrections on WS and ACL assignments; added notes about a shared WS config

Malted/PluginDevelopmentNotes

@@ -52 +52 @@
 === Working on server-side with dms (ApplicationService ===
 
-As a rule of thumb: Whenever you pass the ''ClientState''-Object into a dms.*-call, all necessary ACL- and Workspace-Assignments should be set automatically by DeepaMehta. This happens because the information which "User" is currrently active in which "Workspace" is part of the Session-Cookie.
+As a rule of thumb: Whenever you pass the ''ClientState''-Object into a dms.*-call, the Workspace-Assignment will be set automatically by DeepaMehta. This happens because the information which "User" is currrently active in which "Workspace" is part of the Session-Cookie.
+
+If ACL-Settings are set correctly depends on the availability of a "HttpSession", resp. if the ACL-Module knows who's the currently logged in user. The latter is never the case if your server-side methods are do not have a "HttpRequest"-Scope (e.g. in a Thread or when just embedding the DeepaMehtaService in your Java-Application. In that case, you' will have to take care of setting ACLEntries and a Workspace-Assignments for all the topics/assocs you create manually.
+
+Example given:
+{{{
+    private Topic setDefaultMoodleAdminACLEntries(Topic item) {
+        // Let's repair broken/missing ACL-Entries
+        ACLEntry writeEntry = new ACLEntry(Operation.WRITE, UserRole.CREATOR, UserRole.OWNER);
+        aclService.setACL(item, new AccessControlList(writeEntry));
+        aclService.setCreator(item, USERNAME_OF_SETTINGS_ADMINISTRATOR); // which resolves to "admin" in this case
+        aclService.setOwner(item, USERNAME_OF_SETTINGS_ADMINISTRATOR); // which resolves to "admin" in this case
+        return item;
+    }
+}}}
+
 
 ==== Constructing a composite (complex) topic object imperatively ====
@@ -79 +94 @@
 
 Addendum: Since the "importModels=" property influences the starting order of all plugins, a rule of thumb was identified in Ticket #465: "If your plugin introduces new types, you have to import the "de.deepamehta.accesscontrol" model". Otherwise ACL-Entries may not be set correct during installation of your plugin since the ACL-Plugin is not there to do it's job. 
+
+=== Introducing a shared workspace and set up your topics to editable by all members of this shared workspace ===
+
+A proper workspace assignment in DeepaMehta involves the "Username"-Topic (and not the "User Account"-Topic) to be the: 
+
+{{{
+"Username" (Parent) <- "Aggregation" ->  (Child) "My Workspace" 
+}}}
+
+Furthermore, the topics to be edited by all "Members" of "My Workspace", should be set up to match at least the following ACL:
+
+{{{
+ACLEntry writeList = new ACLEntry(Operation.WRITE, UserRole.MEMBER, UserRole.CREATOR, UserRole.OWNER);
+}}}