There is an important architectural principle that needs to be established. Will Sakai run without Vivo? IIRC the profile design work previously assumed that the answer to this must be 'Yes' and Vivo would just be an optional data source. For me the interesting model would be to invert the logic and make the answer 'No'. There might be a minimal profile service bundle that could come with Sakai code, but full functionality would depend on a Vivo installation. We would need to anticipate that institutional deployments of Vivo might pre-exist Sakai and have been customised in our architectural model. I think this is how identity management is handled in some Kuali apps - Kuali Identity Management as a very basic module for testing, but an assumption of integration with a full identity management system for real installations.
I believe there is work on permissions within the Vivo community, but I have discussed it recently. Did you find Yushan's work on a profile widget pulling information out of Vivo? HTH John On 6 Aug 2012, at 22:24, Simon Gaeremynck <[email protected]> wrote: > Hi, > > I'm working on trying to use VIVO [1] as a possible repo to host all our > profile information on. I've been going trough confluence and the > user/profile bundles to determine how it might tie into Sakai and I'm > slightly questioning if the existing codebase would be sufficient to cover > what we need. > > Afaict, the (current) way to go is by using KERN-739 [2] which was created to > handle this kind of thing. You can express external data-feeds by setting the > 'sakai:source' property on the authprofile node (or any child thereof) to > external. When you do a request to ~/simong/public/authprofile.profile.json, > it will then trigger your ProfileProvider implementation which can deal with > getting the data from the external source. This would also require a > LiteAuthorizablePostProcessor who creates that property upon user creation. > > I've tried this approach and it does work (ie: I'm able to grab external data > out of VIVO and bring it into sakai) but I'm wondering if this would be the > way to go forward. It doesn't look like it was ever meant to handle full > profiles but rather parts of a profile. ex: only publications are external. > I've talked to Ray who has written the persondirectory contrib bundle which > does a similar thing and he seems to be hesitant to use this kind of logic as > it has never been really used (as far as we can tell). > > Some factors that might play a role into all of this are: > - The ability to ACL certain profile data, this is something that VIVO > doesn't provide (again: afaict) and certainly isn't trivial. > - The ability to update profile information from within sakai. This might > need a custom ProfileService impl ? > > Has anyone ever done anything like this or has some advice/ideas on what the > best approach would be? > > I'll be tracking my work against KERN-3081 [3] if anyone is interested. > > Thanks, > > Simon > > > > [1] http://vivoweb.org > [2] > https://confluence.sakaiproject.org/display/KERNDOC/KERN-739+Dynamic+user+profiles > [3] https://jira.sakaiproject.org/browse/KERN-3081 > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev John Norman Director - CARET University of Cambridge [email protected] +44-1223-765367
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
