LTI with Moodle - restrict access to series

[Katrin Scharnowski]

Hi,

now that we have LTI with Moodle working, we are trying to find a good way to restrict access to course-specific series to students/instructors etc. associated with that course. Specifically, we do not want people to be able to share links to the videos. Users who are logged in via the LTI actually do have course specific roles, containing the course ID and their role, such as Learner, Intructor, etc. Those could be used to restrict access to course-specific material, however I cannot find a way to create roles in Opencast. I read in previous threads, that some people create them directly in the Opencast database.

So, I would like to know:

Is there any way of creating arbitrary roles, other than putting them directly into the data base?
If there is no such way, could messing with the data base in such a way lead to any problems?
Is there a better way to restrict access to series for course participants (ideally without having to create local accounts for all of them), that we are not aware of?

Our setup at the moment is an allinone-Server with OC 2.3.2, running on CentOS 7.

Regards,
Katrin

[Paul Pettit]

Hi Katrin,

We are doing this using a simple custom opencast module that syncs our
timetable data (which is pulled from Syllabus Plus and Celcat and
normalised into a staging database by a third party tool) into opencast
and creates all the needed roles and series using the java API if they
don't already exist. This seems to work well (assuming the timetable
data is correct!).

Thanks,

Paul.

> --
> You received this message because you are subscribed to the Google
> Groups "Opencast Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to users+un...@opencast.org
> <mailto:users+un...@opencast.org>.

[Gerhold]

Good day

I also have have the same problem as mentioned above of how to restrict students and lecturers to their respective courses without having to enter the ID in the LTI parameters. This is the one obstacle keeping me from introducing Opencast to the wider staff at my university.

We currently have Panopto integrated with our Moodle LMS which we only got recently also, but we will not be able to maintain it the long run and would like to introduce Opencast as the alternative, but the the above issue is a problem. I also do not have enough time to spend on investigating all kinds of solutions to get it working due to a very limited man power in the systems division; being only one at the moment. I need it just to work is it does with how I have Mahara, Xerte and Panopto integrated in Moodle LMS.

Regards

> an email to users+unsub...@opencast.org
> <mailto:users+unsub...@opencast.org>.

--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to users+unsub...@opencast.org.

[Ruth Lang]

Hi,

as we tested 2.3.2 and LTI with ILIAS, we added via REST service a group (LTI_COURSE_NUMBERS) and included the needed COURSE_IDS.

We left the user field empty. This procedure was repeated if a new courseID was requested.

This made it possible to select the ID for a series and LTI worked for us.

Regards

Ruth

[ypatios]

Hello all,

this is a problem that we also needed to tackle – I mentioned that in my presentation during the 2017 summit.
I’m now happy to share with you our rewritten script, (hopefully) more widely usable/useful.

Feel free to have a look:
https://github.com/llttugraz/llt_videotools/tree/master/acl2oc

Here’s an excerpt from the documentation:
###
This program is a Perl-script which helps update the Access Control List (ACL) of an existing Opencast series. Custom roles can be defined and granted the desired privileges for a given series. Additionally, the respective roles according to a given Moodle course-ID can be generated, so that the use of the LTI-module is meaningful.
###


I’d be delighted to receive your feedback.


Thanks and greetings from Graz,
ypatios

> To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

[most...@gmail.com]

Don't know how moodle works, but is is what we are doing ATM:

- sakai LTI integration returns a context_id

- when scheduling an event, we first try to create a serie with
id=context_id, and ACLs and other metadata retrieved with /lti information

- sakai group is created using curl on server startup, giving the
needed permissiosn to /api/series and /api/events roles

so far, it seems to work, altough we know "setting the id is not a
recommended approach".

We'll do until next version tag+query mechanism is available

[Stephen Marquard]

Hi mostolog,

I don’t quite follow why you need to create the Sakai group “on server startup” unless you’re starting with an empty database? It should only be necessary to create the group once (which can be done through the Admin UI).

Regards

Stephen

 

---
Stephen Marquard, Learning Technologies Co-ordinator,
Centre for Innovation in Learning and Teaching (CILT)
University of Cape Town
http://www.cilt.uct.ac.za
stephen....@uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290

Disclaimer - University of Cape Town This e-mail is subject to UCT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. If this e-mail is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via cs...@uct.ac.za

[most...@gmail.com]

On 14/06/17 13:45, Stephen Marquard wrote:

I don’t quite follow why you need to create the Sakai group “on server startup” unless you’re starting with an empty database? It should only be necessary to create the group once (which can be done through the Admin UI).

'cause we are actually testing the deployment so it's scripted
So: totally agree :)