Hello Judy > All Matterhorn users or potential users: > Given that we will be building on our authorization capabilities in future > versions of > Matterhorn, we're interested in gathering a greater understanding of what > needs > *your* institution may have around authorization. We are particularly > interested in > how granular permissions need to be. > > Currently, the administrator can specify, for any Series, which roles can view > recordings in that Series published to the Engage server. The next step is > likely to > add the ability to specify which roles can "manage" the recordings in the > admin UI. > For 1.3 is it is likely that we will expanding the Series Permissions UI as > was > originally planned for 1.2: > <http://opencast.jira.com/wiki/display/MH/Permission+Management+on+Series+UI > +for+1.2> (the column labeled "Edit" really should be "Manage"...editing the > mockup isn't working at the moment).
Changed the "Edit" to "Manage". There is "Make changes" also, is that identical to "Manage" (cannot edit that mock-up)? > Of course, "manage" is a pretty all-encompassing term. So, some questions > concerning Series-level privileges: > --To meet your needs, will the above work? i.e. Is it okay to allow anybody > that has > management rights on a series to have *all* management rights? > --Or do you need this to be more fine-grained, e.g. something like > <http://opencast.jira.com/wiki/display/MH/Extended+Series+Authorization>? > (This > is only a sketch to demonstrate what more fine-grained authorization might > entail...don't take it too seriously.) Having a quick look at your mock-ups, I'd say that the extended authorization is not necessary for us here at ETH. If I understand your distinction correctly... > And, there are some authorization controls we will need beyond those for > Series. > Some are illustrated on a potential new "Roles" UI: > <http://opencast.jira.com/wiki/display/MH/Roles+page> (again just a sketch as > we > begin to play with ideas...these may not be at a useful or realistic level of > granularity). We'll also need to limit access to capture agents (no sketches > for this > yet). ... I would speak in favour of having sophisticated "admin" roles instead in that - we would like students to do the trimming, without being able to do anything else or - would like to restrict any deletion action (scheduled recordings, recordings) to the actual admin(s). > Basically, what we're interested in is whether there are some Matterhorn admin > activites that you want some of your users to be able to do that you don't > want > others to do. > > If you can respond to this thread with any input on this issue (your reaction > to the > above sketches or questions, requirements that you have, use cases, lists of > privileges, anything) it would be immensely helpful. Or, even better would be > if > you'd be willing to have a conversation with us about this; let us know if > you'd be > willing to be interviewed! Sure - makes a change from talking about metadata... Regards Olaf A. > Please note that this message (and the linked sketches) should not be taken > as any > promise of what Matterhorn authorization will be. We're just exploring needs, > not > even considering technical feasibility at this time. > > thanks in advance for your help, > Judy Stern (and Adam Hochman) > > > Judy Stern > Educational Technology Services, UC Berkeley [email protected] > > _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
