[deepamehta-devel] Upgrading to DM 4.5
jri at deepamehta.de
Wed Jan 21 05:25:07 CET 2015
DM 4.5 is now near release. In conjunction with its new access control concept DM 4.5 introduces crucial changes in the data model. So the upgrade process is technically more difficult than usual. Before releasing 4.5 I want make sure that upgrading will work properly with your particular DM content. So I would appreciate very much when you test upgrading to 4.5 now.
Upgrading performs automatically as always.
You can upgrade any stable DM release (no snapshots!) that is not older than 4.1.
To test the 4.5 upgrade follow the usual DM update procedure:
1) Download the current snapshot (or build the master branch):
2) Copy your `deepamehta-db` folder to the DM 4.5 folder.
3) Start DM 4.5. Your content will be migrated to 4.5 automatically. Infos about the conversion process are marked with multiple hash marks (#####) in the log.
After upgrading 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. The users should have the same edit privileges. All workspaces will get Sharing Mode "Public" as this reflects the pre-4.5 access control semantics. However some differences might occur in DM 4.5:
- Some content might vanish from topicmaps, in particular user accounts topics and username topics as these are not public anymore in 4.5.
- Topics/associations which had multiple workspace assignments can not be edited anymore. This is because these objects will be not assigned to any workspace at all in 4.5 due to ambiguity. (In 4.5 every topic/association is assigned to exactly ONE workspace.) While the upgrade process these topics/associations are reported as ''ambiguous'' in the log.
Note: currently in 4.5 you can't re-assign a topic/association to a(nother) workspace interactively via Webclient (only via API). Manipulating the Aggregation associations have no effect. DM 4.5 stores the workspace assignment internally (as a property). The Aggregation associations remain there as a means for visualization.
The following hints might inform your testing:
- When loggin in/out the parts of the displayed topicmap might change due to changed authority. Note: a topicmap can combine content from several workspaces and thus several access "realms".
- Every user has a private sphere as represented by her's Private Workspace. When you create a User Account DM creates the corresponding private workspace.
- User accounts can only be created by administrators. Members of the System workspace are regarded administrators.
- The "admin" default user is member of both, the DeepaMehta workspace and the System workspace.
- User accounts are not public visible. A user can reveal/edit only its own user account. Technically a User Account topic and the corresponding Password topic are assigned to the user's private workspace, and the Username topic is assigned to the System workspace.
- System is a "Public" workspace, but with one exception: its content is visible (not editable!) only to logged in users (regardless whether they are System members).
- Membership relationships (between a user and a workspace) are represented by the new Membership association type.
- A Membership to a workspace can only be created by users who have WRITE access to that workspace. These comprise the workspace owner, and all workspace members (provided the workspace has sharing mode "Collaborative" or "Public").
- When a user creates a workspace she becomes the Owner of that workspace. For a workspace owner no explicit Membership association is created. (It would be redundant.) The owner's membership is implicit.
- A Membership association can be deleted by users who have WRITE access to the very workspace. Technically a Membership association is assigned to the very workspace.
- When a user leaves a workspace -- by deleting or retyping hers Membership association -- the Webclient GUI is updated immediately (just like after logging in/out) in order to reflect the decreased authority. Pressing the Reload button is not necessary.
- Searches are private. Nobody can see what another user is searching for. Technically a Search topic is assigned to the user's private workspace.
- Anonymous searches, as performed by users who are not logged in, can be deleted by all users who have WRITE access to the DeepaMehta workspace. An anonymous user can't delete the Search topics she creates. Technically anonymous searches are assigned to the DeepaMehta workspace.
- A user can create further private on her own will.
- A user who have no WRITE access to a topicmap can't create anything. But she still can manipulate the topicmap by changing its view properties like geometry, visibility, colors. She can also search/reveal things. However, these view changes are not persistent.
- Each topic/association provides a "Get Info" command which brings up a dialog telling you (beside other things) who is the Owner of that object. This is the owner of the workspace the object is assigned to. This info is crucial when DM determines your permissions for that object.
For introduction-level hints about DM 4.5's new access control concepts see this posting:
So, in case you encounter any problems/oddities with your DM content after upgrading to 4.5 or if you feel something does not behave as it should (related to the above hints) please let me know here. Your feedback is very much appreciated.
In particular I'm interested whether the content of the Kiezatlas production instance will migrate properly to DM 4.5. As far as I can see we can test this solely at the data-level, without installing the actual Kiezatlas modules (which must possibly adapted to DM 4.5 first).
Last but not least DM 4.5 brings one crucial improvement for developers: plugin services can be made available in migrations through injection. This might help the plugin developers when it comes to writing the 4.5 migrations.
DM 4.5 is scheduled for release at the end of this month.
More information about the devel