Current version

The current version of the integration assigns ACL rules to every series and episode. Moodle embeds the episodes using an iframe. The authentication is done via LTI. Via a webservice call from opencast, Moodle tells opencast, which courses the user is enrolled in. This list of courses in combination with the ACL rules attached to the episode allow opencast to determine, which user is authorized to access a specific episode.

Current Drawbacks

The current integration has several drawbacks. The authentication/authorization via ACLs...

1. is costly due to several webservice calls.
2. is intuitive for developers and teachers.
3. does not allow to use the Moodle availability features.
4. is tricky to configure correctly.
5. is inflexible, since changing the ACL roles takes time and is not easily possible via bulk operations. Therefore I (Tobias Reischmann) propose the following new approach:

New approach

Moodle delivers an own version of the paella player to the user. The student does not authenticate against the opencast system at any time. Moodle does that for the student. Also Moodle determines the access privileges of each student independent of any ACL rules. Thus, the enrolment of a student and availability constraints of activities are the only limitations here. Moodle then queries the required media-urls from opencast with an API user. It is possible to configure opencast in a way that it signs all urls it delivers through the API. This way, it can be limited how long specific urls can be used. Moodle then embeds the retrieved urls into the paella player instance it delivers to the student.

For the embedding of episodes (as an alternative to LTI) two new activity modules could be added to moodle. These could have a list of all available episodes within the course, which can be linked to this activity instance. The activity instance then delivers the paella player to view this episode. The second activity module could view list of episodes within a series.

Advantages

1. The configuration of this interaction is much easier.
2. The loading time should decrease, because much of the interaction between Moodle and Opencast that happened within the page load of the user is thrown away.
3. Also the filter should be easier to implement. It could for instance also be possible to embed a video, which has not yet been fully uploaded. In these cases, Moodle could simply provide a thumbnail with some meta-data of the video, which will be soon available at this stop within the course. (Maybe also for planned videos)
4. If would be easier to reuse episodes across courses. It might be still relevant to keep the concept of series attached to courses. However, it might be interesting to allow multiple series attached to one course.

Disadvantages

1. This approach unfortunately does not make the whole ACL implementation obsolete. Teachers, for instance, still need the privileges to upload videos via opencast studio. This is only possible via ACLs.
2. The LTI integration for students does no longer work. However, since older episode already have the necessary ACLs the two systems should be backwards compatible and no update procedures for existing embeddings would have to be implemented.

Other nice ideas

What would be really nice in the future is the following use case:

1. A teacher turns course editing on.
2. The teacher drops a huge video file into the course content.
3. The teachers is prompted with the question whether she wants to upload the video directly to opencast.
4. The teacher selects "Yes, of course!" and selects an opencast series attached to this course.
5. Also the teacher adds meta information, such as the title and the author.
6. The video is uploaded to opencast within the selected series.
7. At the spot, where the teachers had dropped the video file, an mod_opencastepisode is created, which points to the new created opencast episode id.
8. Till the video has been fully processed by opencast and is offered via the relevant publication channel (this can be set in the admin settings of Moodle), the activity instance only displays the title of the video and other meta data. This could be done nicely be providing maybe even a thumbnail and a text which promises that the video is available soon.