[deepamehta-devel] Creating Topics programmatically as part of Migrations

[Jörg Richter]

Hi Malte!

you do everything right. What you're missing is the Access Control setup for the new topic. That comprises
	- a "Creator" assignment (who is the creator of the topic?)
	- an "Owner" assignment (who is the owner of the topic?)
	- entries for the Access Control List (what user role is allowed to perform an operation?)

Normally a default Access Control setup is done automatically for every topic that is a) created interactively, or b) created programmatically, triggered by an HTTP request. In both cases the current user session is identified by the cookie.

BUT -- and this is your problem -- in migrations it is different: Topics created in migrations will get *no* default Access Control setup! This is due to the fact that a migration is triggered by the server itself, and not through a HTTP request. There is no cookie and thus no user context.

For every topic you create in an migration, you must care for its Access Control setup yourself. Unfortunately this goes along with another shortcoming: within a migrations you have no access to plugin services (see https://trac.deepamehta.de/ticket/324). That is, you can't consume the Access Control which would assist you with creating the required setup.

For the moment the best practice is:
- In your plugin consume the Access Control Service
- Once the AC service arrives: For every topic created in a migration:
	- Check if it is already setup, e.g. be checking if it has a creator assigned
	- Only if not: set it up by the help of the AC service (the 3 settings mentioned above)

	acService.setCreator(topicId, username);
	acService.setOwner(topicId, username);
	acService.createACL(topicId, acl);

Also see dgf's MailPlugin.java. There exists exactly the same situation you describe.
https://github.com/dgf/dm4-mail
Let me know if you need further help.


On Nov 24, 2012, at 18:44, Malte Reißig wrote:

> As I dont have a custom workspace in use, as the normal prerequisite I
> associated all my custom topicTypes with the default workspace
> DeepaMehta ("de.workspaces.deepamehta"). BTW: It would be nice if a
> plugin could define some sort of default "Workspace" for all it's own
> Topic- and AssociatonTypes.

That's a good idea! I filed a ticket:
https://trac.deepamehta.de/ticket/371


> Furthermore I related all newly created instances to the default
> workspace through executing the following command in my Migration:
> 
> dms.createAssociation(new AssociationModel("dm4.core.aggregation",
>    new TopicRoleModel(newTopic.getId(), "dm4.core.whole"),
>    new TopicRoleModel("de.workspaces.deepamehta", "dm4.core.part")
> ), null);

This looks correct.
Note: a workspace assignment is not necessarily required in the regard of Access Control. However, it *is* required when you want exploit the MEMBER user role (as appearing in an ACL entry) for workspace member-based access.

Another note: if you were not in a migration you would use the Workspaces service's assignToWorkspace() call which would be more comfortable.


Thanks for your question!
Indeed, it points to serious issues of the DM plugin framework. Migrations in conjunction with Access Control must definitely become less cumbersome.

Cheers,
Jörg