Hi,
For now we disabled the JS check - that gets us up and running (once we
have these permission problems fixed)
I would like to make some suggestions and could come up with some
suggestions - I'm a bit swamped right now but would gladly do this in
the 1.4 timeframe
I think we need something like 2 new methods:
boolean roleExists(String)
List<role> searchRoles(string)
To support the current functionality. I need to look a bit at how that
code is actualy called though ...
D
On 02/09/2012 02:09 PM, Tobias Wunden wrote:
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]
_______________________________________________
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
