opencast-moodle / moodle-block_opencast Goto Github PK

• Add an admin setting 'group_name' from type text. Use a heading section "Access Policies".
• Change apibridge->create_acl_group() so that the group name from this setting is used as $params['name']. Since the static function api::get_course_acl_group_name from the repository plugin is only called here, this functionality can be moved to the block!
• Allow placefolders [COURSEID] and [COURSENAME], which are automatically replaced by course->id and course->fullname. You can use str_replace() for that. (http://php.net/manual/de/function.str-replace.php)

Issue #22 requests to be able to manage to manage student access. To implement that it is needed to change the ACLs in Opencast. In the current block settings it is possible to define which ACLs are added to uploaded videos. This list could be extended with a checkbox to manage wether a rule is permanent (e.g. for admin or instructor access) or not (e.g. for student access).

The problem is that get_user_max_upload_file_size, which is called frequently within the implementation of filemanager, sets the max upload size to the minimum out of php, site, course and module limit. This way the block is not able to override the other limits in the moodle site.

I have seen that the default for \block_opencast\task\process_upload_cron is to run only every 24 hours at midnight whereas the default for \block_opencast\task\process_delete_cron is to run every single minute.

I am wondering if it shouldn't be at least the other way round (let the upload job run every minute and let the delete job run only at midnight) or even better let both jobs run every minute.

If anyone is able to tell me that there was a design goal for this default schedule, I would be curious to hear about it.
Otherwise, I would prepare a pull request to change both jobs to run every minute.

It would be nice to be able to configure a help link that would be displayed for the users trying to use the block.

• Add a admin setting 'acl_roles' to the heading section "Access Policies".
• The setting is represented by a table with two columns.
• The first column contains the name of the role, e.g. ROLE_ADMIN or ROLE_GROUP_MOODLE_COURSE_[COURSEID].
• The second column contains the name of the action, which the role gets assigned, e.g. read, write, annotate.
• The admin should be allowed to enter arbitrary strings to both fields.
• The admin should be allowed to enter and delete as many entries as he likes.
• The first column is no primary key! It has to be possible to create the entries (ROLE_ADMIN, read) and (ROLE_ADMIN, write) without conflict!
• These ACL configurations should then be used in apibridge->create_event(), apibridge->delete_acl_group_assigned() and apibridge->ensure_acl_group_assigned().
• These roles column should again be able to use the placeholder [COURSEID]!

https://github.com/unirz-tu-ilmenau/moodle-block_opencast/blob/f3afe620566a31eeb5e6c51af25014ebf5dacb3d/classes/local/event.php#L134

Instead of only allowing to upload a new video, a teacher could be allowed to choose from all videos from other courses and copy single videos to the series of the current course. This way, old videos could be reused. Through copying the videos it is possible to apply different ACLs to the videos and to distinguish them for instance in the annotation tool.

Usually we use the block together with the MoodleRoleProvider in Opencast. Thus, I would set the respective Roles as default in Moodle.

ACL rules should be applied to whole series as well.

In https://github.com/unirz-tu-ilmenau/moodle-block_opencast/blob/master/classes/local/addvideo_form.php#L41, the block accepts the filetype group "video" for uploading. Looking at https://github.com/moodle/moodle/blob/master/lib/classes/filetypes.php, this group resolves to many filetypes and many of them might not be suitable or desired for uploading to Opencast.

Changing the video group to web_video would be an improvement, but you would still allow types like flv or swf which you most probably don't want to process in Opencast.

That's why I would propose to add an admin setting to the block to let the admin set a list of mimetypes which he want to allow for uploading. This can be realized with the Moodle mimetype chooser which is already used for example in mod_assign.

As an administrator I would like to be able to configure if the users see the column with the publication channels in the list of the published videos.

Currently, the metadata for an event which is uploaded to Opencast with block_opencast is only generated automatically from the video filename as far as I see. And we all know the users / teachers who label their files just with non-speaking filenames or with some strange complex scheme which only they understand.

I would like to propose to add functionality...

• ... which lets users set at least the title of the event manually. Don't rely on the fact that users know how to rename files in the Moodle filepicker. Show them a mandatory input field for the title of the uploaded videos instead.
• ... which lets users change the event metadata after the video has been uploaded and processed if needed
• ... which lets Moodle download the whole metadata catalog of Opencast and provide optional input fields for all metadata fields so that the whole catalog can be filled from within Moodle.

Especially when series name is empty, Opencast will throw a 500 server error message.
Thus, we should check all configurations for validity.

Offer a button under the capability of an opencast admin, to directly create the opencast series with all ACLs without uploading a video.

Add a setting to the overview block, which allows to select the corresponding opencast series from a dropdown. This should only be possible with a specific capability. For a lot of series in a system, we should think about something like a searchable dropdown.

We should verify that the video exists which should be uploaded (during the upload process).
Otherwise an error will be thrown and the cron job will stop.

• Which Opencast Role have to be assigned to the technical Moodle User.
• Add recommendation towards: which Moodle capabilities should be assigned to which user.

As an instructor I need to be able to manage student access to my uploaded videos. It should be possible to remove student access to a video without deleting it and it should be possible to add these rights again later on.

Currently, it is pretty time consuming to create many ACL Rules.
We just created 16 Rules: 4 Roles and 4 Actions. Since you always have to click on "Add" and then scroll down again, it is not very easy to use. Following suggestion:
Remove the input form and replace it by a button, which adds a new line to the table.
This could also be done using Ajax.
Then the data is added directly in the table. We have to think about data validation here. It should not be possible to save empty roles.
Further, I would suggest to change the storage of actions from one in each line to a comma separated list. This does not necessarily change the way of data storage, but the way it is displayed.

If a video has to go through post production (for instance cutting) before it is actually published, it would be nice to show this to the teacher.

Currently the list of events shows the date, start time and title of the events. This should be extended with the following data:

• If the start and end time are not the same (this is the case with uploads) the end time should be shown as well.
• If a location is given this should be shown as well.

Hello,
I've got the following "risky" error message during the phpunit test:

Moodle 3.5.1+ (Build: 20180831), ref: refs/heads/MOODLE_351+_STABLE
Php: 7.0.30.0.9.1, pgsql: 10.5 (Debian 10.5-1.pgdg90+1), OS: Linux 4.17.0-0.bpo.3-amd64 x86_64
PHPUnit 6.5.12 by Sebastian Bergmann and contributors.

1. block_opencast_upload_testcase::test_upload
   This test printed output: proceed: 577000
   Job failed due to: moodle_exception: Username for Opencast API user is not setup correctly, go to settings of block opencast to fix this in /var/www/moodle/admin/tool/opencast/classes/local/api.php:93
   Stack trace:
   0 /var/www/moodle/blocks/opencast/classes/local/apibridge.php(466): tool_opencast\local\api->__construct()
   1 /var/www/moodle/blocks/opencast/classes/local/apibridge.php(499): block_opencast\local\apibridge->create_course_series('157000')
   2 /var/www/moodle/blocks/opencast/classes/local/upload_helper.php(304): block_opencast\local\apibridge->ensure_course_series_exists('157000')
   3 /var/www/moodle/blocks/opencast/classes/local/upload_helper.php(432): block_opencast\local\upload_helper->process_upload_job(Object(stdClass))
   4 /var/www/moodle/blocks/opencast/tests/upload_test.php(79): block_opencast\local\upload_helper->cron()
   5 [internal function]: block_opencast_upload_testcase->test_upload()
   6 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestCase.php(1071): ReflectionMethod->invokeArgs(Object(block_opencast_upload_testcase), Array)
   7 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestCase.php(939): PHPUnit\Framework\TestCase->runTest()
   8 /var/www/moodle/lib/phpunit/classes/advanced_testcase.php(80): PHPUnit\Framework\TestCase->runBare()
   9 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestResult.php(698): advanced_testcase->runBare()
   10 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestCase.php(894): PHPUnit\Framework\TestResult->run(Object(block_opencast_upload_testcase))
   11 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestSuite.php(755): PHPUnit\Framework\TestCase->run(Object(PHPUnit\Framework\TestResult))
   12 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestSuite.php(755): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
   13 /var/www/moodle/vendor/phpunit/phpunit/src/Framework/TestSuite.php(755): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
   14 /var/www/moodle/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(546): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
   15 /var/www/moodle/vendor/phpunit/phpunit/src/TextUI/Command.php(195): PHPUnit\TextUI\TestRunner->doRun(Object(PHPUnit\Framework\TestSuite), Array, true)
   16 /var/www/moodle/vendor/phpunit/phpunit/src/TextUI/Command.php(148): PHPUnit\TextUI\Command->run(Array, true)
   17 /var/www/moodle/vendor/phpunit/phpunit/phpunit(53): PHPUnit\TextUI\Command::main()
   18 {main}

Please could you have a look at this error.

Cheers,
Michael

It should be possible for users to delete uploaded videos from Opencast. In Opencast this is a two part process. First the video has to be retracted from everything and only then it can be deleted.

If you somehow get into an error state, in which a seriesid is set, which is not present in the OC system, the block has many unexpected behaviours.

In Opencast one might have configured groups of users which should have access to every recording / video in the system. Therefore it would be useful to be able to configure access policies which are added to every recording / video that is being uploaded via the Opencast block in Moodle.

Currently, the upload jobs selected for a cron run are not selected at random but ordered by id.
We experienced an error state at two of our upload jobs (see #28).
Since we set the maximum amount of upload jobs to two, every cron job these two upload jobs were processed. This way, no other job could be uploaded.
We should think about a rotation of the processed upload jobs, for instance ordered by a new field 'lastprocessed'.

At the moment the block checks whether a video has been uploaded before. If that is the case the access policy for the video is changed.

This should be optional as having the same video in multiple series is a use case.

As an administrator it is possible to create a new series for a course. When doing so one is prompted to enter a series name. This should be pre filled with the course name.

You get a few warnings when uploading a video:

• undefined property: line 365 ($event->newlycreated), upload_helper
• try to get property of non-object: line 331 & 378 ($series->identifier), upload_helper

• Add an admin setting 'series_name' from type text. Use a heading section "Access Policies".
• Change apibridge->get_course_series() and apibridge->create_course_series() so that the series name from this setting is used as title]. Since the static function api::get_courses_series_title from the repository plugin is only called here, this functionality can be moved to the block!
• Allow placefolders [COURSEID] and [COURSENAME], which are automatically replaced by course->id and course->fullname. You can use str_replace() for that. (http://php.net/manual/de/function.str-replace.php) See #6

Most workflows are just used for inclusions. These should not be used directly. Opencast has the notion of tags that determine in what situations running a particular workflow does make sense. In 5.x these are:

• upload: Usable for uploaded media
• schedule: Usable for scheduled events
• archive: Usable for archived media
• delete: Usable for deletion of events with publications
• editor: Usable from the video editor

Before 5.x there was a -ng suffix for all but the last tag.

When querying /workflow/definitions.json the tag is represented as either:

// no tags
{ "tags": "" }

// one tag
{
  "tags": {
    "tag": "archive-ng"
  }
}

// two or more tags
{
  "tags": {
    "tag": ["schedule-ng", "upload-ng"]
  }
}

I would suggest to at least filter out the no tags case.

It would be nice, if the list of videos within the block would also display the list of planned but not yet recorded videos.

We should have a look, how to move the custom admin settings page to use the admin config features of moodle. For instance, that new config field can be suggested for updates.

It is required by some of our teachers, to be able to restrict the visibility of a video based on the membership in moodle groups.
This could result in new ACL rules as G42_Learner (for the membership in the moodle group with id 42).

Since the resource we are requesting in validation is only accessible with admin rights, we should change the validation to use workflow/definitions.json. The access rights for this can be given through ROLE_UI_EVENTS_CREATE
With this we could also offer an dropdown for workflows.

Unfortunately I don't remember under which conditions exactly, but the following lines gave me an error when deleting a video:
https://github.com/unirz-tu-ilmenau/moodle-block_opencast/blob/8a62f6b2438ae32042adbf7cd45f8dbd5b497dca/classes/local/apibridge.php#L718-L725

I think we should return inside the if block. Because afterwards $courseid doesn't have a valid value which means $series won't either and the call to $series->identifier will fail.

• Add a setting group_creation as a checkbox to the admin settings. Use a heading section "Access Policies".
• Change upload_helper->process_upload_job so that STATUS_CREATING_GROUP is skipped, if group_creation is false.

The block shows the scheduled events for a series with the correct date and title but the status is still given as "Processing". The status should be "Scheduled".

A while ago this CSS rule was introduced to the boost theme:

// Minimum height required for a menu in a table inside a scrollable div.
.no-overflow > .generaltable {
    margin-bottom: 0;
    min-height: 10em;
}

But that CSS rule only applies to one of the two tables on the overview page:

In my opinion the two tables should either both have the min-height or none of them should have it.

Done

In the current version of the block, all default values, which are defined by the mform, are overriden and thus have no effect. This makes the plugin very difficult to setup.

After a video has been uploaded it remains in the moodledata folder. Is this intended?

I think this plugin should locally delete the video file once it has been uploaded (or at latest once it has been successfully processed).

The maximum upload limit of each filepicker is limited by a global setting, which is usually not that high.
For opencast videos it is important that videos up to some GB can be uploaded. For this reason an additional setting should be added, which allows to specify the maximum upload limit for opencast videos. This than has to be passed as a parameter to the creation of the filepicker in add_video.php.
There is an example for this parameter in the moodle docs: https://docs.moodle.org/dev/Using_the_File_API_in_Moodle_forms#Using_the_filepicker_element

The checkmark for 'publishtoengage' is always unchecked. Even if you previously checked it. So every time you change something in the settings you need to make sure to check 'publishtoengage' again or else it will get deactivated.

The problem is a simple typo:
https://github.com/unirz-tu-ilmenau/moodle-block_opencast/blob/f3afe620566a31eeb5e6c51af25014ebf5dacb3d/adminsettings.php#L147

As an administrator I want to be able to create a new series for a course and select an existing series to copy all or some content from. The user should be able to choose which videos to copy.

Duplicating the event in Opencast could be realised using a workflow, provided that Opencast includes this PR opencast/opencast#23

Hello,
we are wondering if you could add a column to the list of released videos at blocks/opencast/index.php that contains the URL to each video.
The reason we would like to have such a feature is that we don't trust our users to find the video they want to embed (in the Atto editor) via "Media", "Browse repositories..." and "Opencast".

Is this something you would consider?

If not, would you instead consider refactoring the way this table is generated in index.php: https://github.com/unirz-tu-ilmenau/moodle-block_opencast/blob/f5328cd42241ccf68f324873bf9c154ac9a2af84/index.php#L157-L194 so that the table is created by a method of the renderer and/or a template? This way we would be able to override the renderer or template in our theme and add the desired column this way.

When upgrading from older versions an error is thrown:

-->block_opencast
++ 2018082800: Success (0.02 seconds) ++
Default exception handler: Cannot downgrade block_opencast from
2018082800 to 2018082800. Debug:
Error code: cannotdowngrade

• line 361 of /lib/upgradelib.php: downgrade_exception thrown
• line 118 of /blocks/opencast/db/upgrade.php: call to
  upgrade_block_savepoint()
• line 1005 of /lib/upgradelib.php: call to xmldb_block_opencast_upgrade()
• line 514 of /lib/upgradelib.php: call to upgrade_plugins_blocks()
• line 1857 of /lib/upgradelib.php: call to upgrade_plugins()
• line 182 of /admin/cli/upgrade.php: call to upgrade_noncore()

!!! Cannot downgrade block_opencast from 2018082800 to 2018082800. !!!
!!
Error code: cannotdowngrade !!
!! Stack trace: * line 361 of /lib/upgradelib.php: downgrade_exception
thrown

• line 118 of /blocks/opencast/db/upgrade.php: call to
  upgrade_block_savepoint()
• line 1005 of /lib/upgradelib.php: call to xmldb_block_opencast_upgrade()
• line 514 of /lib/upgradelib.php: call to upgrade_plugins_blocks()
• line 1857 of /lib/upgradelib.php: call to upgrade_plugins()
• line 182 of /admin/cli/upgrade.php: call to upgrade_noncore()
  !!

This is due to an invalid order of savepoints within the upgradesteps.

If an upload job is uploaded to opencast the status of it is set to 27 -> uploaded. However, there are still some things to do. When the event in opencast is deleted before moodle has the chance to work on these jobs, it will enter an error state for these jobs. We should think about a way, how to escape such error states.
The described one should first of all set the upload job to failed.