David, do you want to come up with a patch for the role provider? You mentioned at Oxford that you think that the role provider should be able to list (paged) roles?
Tobias On 27.01.2012, at 09:52, David Horwitz wrote: > Hi Tobias, > > On 01/27/2012 10:22 AM, Tobias Wunden wrote: >> Hi David, >> >>> I see that in the Series UI in engange one can no longer add Roles that >>> aren't returned by a Role provider. I believe this is a recent change and I >>> think a problematic one. >> I am not aware of that change, but it seems to make sense since the role >> provider in the end is used to do authorization. Giving the user the ability >> to add roles that cannot be evaluated at runtime may not be what you want >> and *may* in most cases lead to speling mistakes go by unnoticed. >> > Hmm if thats the case I missed something major and may have a major issue > here. Mapping SIS information to group information in a system is a non > trivial task and one I hoped to shelve past our launch (I also think the > RoleProvider is inadequate for a sizeable organization). > > OK our case is this - LTI passes role and context information to the producer > (Matterhorn). This is mapped to a role (or roles). So LTI in Matterhorn will > construct a role like: > > 206889d6-569b-4fd3-8014-d0e699f710df_student (In Sakai, Moodle etc the id > part may be different) > > There is no way that that the RoleProvider can know these ahead of time (it > would break the point of the loose integration), however an admin can know > them and add them to a series. The only other way to limit would be for the > LTI key to be highly trusted and for Matterhorn to map the supplied user to a > known user with group information - this is in the works but not ready yet. > > Also I would like our admins to give the series access to the SIS groups so > that when the integration work is complete access is available through non > LTI channels. >>> Currently we have 3898 courses being offered this year, Seeing as they >>> define at least 2 roles each we're now up to potential 7796 roles (and in >>> reality there are more than 2 roles in a course). So we're loading >>> matterhorn with role definition in the thousands for the hand full that >>> need tight permission handling. >> I think the original idea behind this was that most universities would have >> a database that would state that a given student is attending this and that >> course (or is at a certain stage in his educational carreer) and that those >> "affiliations" (provided by university system) would be used as roles. >> >> However, if you need to add those roles manually, I agree that it's a >> daunting task. One question though: My understanding is that if you don't >> add any role information, the recording will be open, which I think is what >> you want for most series, correct? >> > Actually no - having to have all lectures public will be a serious barrier to > adoption at UCT - most of our users are not ready for that so we want to > offer them the opportunity to limit it to the course members. > > There are 2 issues here we may be conflating: > > 1 - UserProvider supplying user details and the names of the groups the user > belongs to > 2 - Groupprovider - supplies all the know group names to matterhorn. > > 1 is not the issue here and my understanding this is what's used to answer > Authz questions. 2 is the issue as its now being used to do more than suggest > valid names. > > D > > >> Tobias >> >> _______________________________________________ >> Matterhorn mailing list >> [email protected] >> http://lists.opencastproject.org/mailman/listinfo/matterhorn >> >> >> To unsubscribe please email >> [email protected] >> _______________________________________________ >> > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
