[deepamehta-devel] Upgrading a plugin to the more collaborative DM 4.5

[Jörg Richter]

On Jun 9, 2015, at 12:57, <mre at deepamehta.de> <mre at deepamehta.de> wrote:

> Hey there,
> 
> here are some thoughts or questions i wanted to share with the dm-core
> developers so my understanding of this is right before i start to implement
> the changes across all my plugins.
> 
> 1 I got an no read permission error when fetching user-topic "admin" in my
> old migration code. The plugin sets up "admin" as the first member of a new
> "Wikidata"-workspace (if the other wikidata plugin has not already done
> so). Now i  guess i have to use the WorkspaceService in my Migration and
> make admin "join" my workspace, right? OK, good.
> 
> Checking the source code i see that there is no such thing provided by the
> WorkspaceService but the AccessControlService has a "createMembership" and
> a "isMember" method - so i will go with these and assume that is the
> envisioned way.

Yes, use the AccessControlService's createMembership() and isMember() methods to create and check memberships.
https://trac.deepamehta.de/ticket/592#comment:11

Note: these 2 methods are part of the Access Control service (not the Workspaces service) to avoid circular dependencies.
The Access Control module clearly depends on the Workspaces module (as access control is mainly governed by workspace memberships). The User type is part of the Access Control module (as it manages user privileges), and a Membership involves a user. If the 2 membership methods would be part of the Workspaces it would in turn depend on the Access Control module (in order to use its User type) producing a circular dependency.
Think of a membership as a Access Control concept.

Hint: DM 4.6 introduces the "System" authority which has unrestricted access to the database. The System authority is in effect in particular for migrations as they often perform DB-wide administrative tasks. https://trac.deepamehta.de/ticket/764

> 2 I often install/migrate (in nearly all my plugins) configuration topics
> so the user ("admin" resp.) has the chance to adjust the behaviour of the
> plugin, e.g. in the wikidata dump import settings etc. pp.
> 
> To get this right (=the needed "edit"-functionality for some user like
> e.g. "admin") the way i understand the new ACL features in 4.5, the
> cleanest and possible most future-proof way would be to assign all my topic
> instances to:
> 
> 2.1) a workspace where members have "edit" permissions on topics and 
> 2.2) make sure that "admin" is a member of that very workspace. 
> 
> Another question:
> Since there is now a "System" workspace suggesting by its permissions to
> cover exactly the scope of administering certain system-wide settings of a
> plugin - i could also discard my custom workspace and assign my config
> topics to this, no good?

Yes, indeed, the "System" workspace is a good home for your config topics. Members of the System workspace (as well as the workspace owner of course) are regarded administrators. The "admin" user is the owner of the System workspace. Content of the System workspace is readable by every logged user and writeable only to members (as well as the workspace owner of course).

See hints in "[deepamehta-devel] Upgrading to DM 4.5":
http://lists.deepamehta.de/pipermail/devel-lists.deepamehta.de/2015-January/000570.html

> Last question before the last:
> The most easy type assignment for me would be to assign all my "custom
> type definitions directly to the "DeepaMehta" workspace, right?
> What would be the benefit (for end-users from their experience) when i
> assign all types of a plugin to a custom workspace?
> Or in other words: How does my choice (as a plugin dev) on the relation of
> "custom types and their relation to a workspace" affect other plugin devs
> and normal users of DM 4.5? Of course i would like to learn more about the
> effects of my choices in advance.

By assigning your types to a certain workspace you can control who is allowed to create instances of your types.
To create an instance a user needs both:
	- READ access to the type.
	- WRITE access to the current workspace (as selected in the Webclient).
The Webclient's Create menu shows only types the user has READ access to.
When you assign your types to a public workspace like "DeepaMehta" every member (and the workspace owner of course) is allowed to create instances. When you want restrict instance creation assign your types to a "Collaborative" or "Confidential" workspace. Only members (and the workspace owner of course) can create instances then.
https://trac.deepamehta.de/ticket/592
https://trac.deepamehta.de/ticket/592#comment:22

> And the special case of the dm4-sign-up module, open question:
> To which workspace should a self-registered user account become assigned
> during creation (there must be one) and would you want to be able to
> configure one (or more) workspace uris for which the self-registrant will
> get automatically a membership?

To create a User Account programmatically use the AccessControlService's createUserAccount() method. Workspace assignment is automatic. No workspace cookie is needed.
createUserAccount() performs in particular:
	- creates a User Account topic (consisting of Username and Password child topics).
	- creates the user's Private Workspace.
	- assigns the User Account and Password topics to the (just created) user's private workspace.
	- assigns the Username topic to the System workspace.
IMPORTANT: when invoking createUserAccount() via REST API you must suppress the automatic workspace assignment by adding "?no_workspace_assignment=true" to the request.
https://trac.deepamehta.de/ticket/752
https://trac.deepamehta.de/ticket/751#comment:14

More general info in "[deepamehta-devel] Upcoming DM 4.5: extended collaboration and privacy":
http://lists.deepamehta.de/pipermail/devel-lists.deepamehta.de/2014-December/000562.html

Cheers,
Jörg