We are working on a integrated system with the DIY to support multi user OTrunk Reporting.
Originally we planned for a system where any ReportTemplate could be applied to any compatible AuthoredContent and group of users. However the OTrunk system isn't flexible enough for this approach yet. So instead we need to restrict the ReportTemplate to one AuthoredContent. See the "Possible Improvement" below so this restriction can be relaxed.
ReportTemplate is bound to a particular AuthoredContent. The DIY needs to fill in the group of users. And the url to the AuthoredContent. The url to the AuthoredContent is filled in so the DIY can serve the AuthoredContent either directly from the source or from its cache.
Here is an example of the final result:
This would be generated from a "template" where the OTMultiUserRoot looks like this:
The code for modifying the otml file should look for the OTMultiUserRoot element with a local_id attribute of multi_user_root and add the userDatabases element from above:
The template would have the following element in it:
It is quite likely that the report template will include other otml files. So the other <OTInclude> elements inside of <includes> should be preserved.
There is definitely a lot of places where this approach could be improved, but this seems the most practical for right now. There is one improvement that seems practical but since I'm not doing the work I don't know. If this improvement is not clear, or doesn't fit with how the DIY should be heading, then it isn't worth doing. It is more important to get something flexible, working quickly, even it is a little cumbersome.
The ReportTemplate otml will probably be used for several activities. The only change will be the references to the objects in the AuthoredContent. These changes can be encapsulated in the <idMap> element, like they are above. So parts of the idMap could be generated by the DIY this would eliminate the need for the mulitple copies. And we could get closer to our original design.
This could be done by adding a list of "bindings" to the relation between an DIY activity and ReportTemplate. These "bindings" would be of the form:
Both items are just strings.
These would be added to the <idMap> element using this form:
It is possible that the report template will have other <idMapping> elements inside of the <idMap> these should be preserved.
These binds should be added to the "relation" between the DIY Activity and the ReportTemplate so that multiple report templates can be connected to a single DIY Activity. And each report template might require a different set of bindings.