$plugin->component = 'mod_ivs';
$plugin->release = 'v1.13.809';
$plugin->version = 2022092000;
$plugin->requires = 2014051200;
$plugin->maturity = MATURITY_BETA;
$plugin->cron = 0;
$plugin->dependencies = array();

I see a lot references to isteacher type calls that use role-based checks - also what appears to be some reliance on role archetypes instead of correctly implementing the use of Moodle capabilities - this should really be revisited and rewritten to rely on moodle's capabilities correctly.

DB: Postgresql14
Moodle Version: 4.1.3
PHP: 8.0

== Moodle von 4.1.3 (Build: 20230424) (2022112803) auf 4.1.3 (Build: 20230424) (2022112803) aktualisieren ==

Die Moodle-Dateien wurden auf Ihrem Server verändert. Moodle wird
automatisch auf die Version 4.1.3 (BUILD: 20230424) (2022112803)
aktualisiert. Danach können Sie nicht mehr zur alten Version
zurückkehren. Beachten Sie, dass der Vorgang sehr lange dauern könnte!

Möchten Sie die Aktualisierung des Servers wirklich starten?

y (yes=ja) oder n (no=nein) eingeben
: y
-->mod_ivs
Default exception handler: Datensatz kann nicht in der Datenbank gefunden werden Debug: SELECT cm.*, m.name, md.name AS modname 
              FROM {course_modules} cm
                   JOIN {modules} md ON md.id = cm.module
                   JOIN {ivs} m ON m.id = cm.instance
                   
             WHERE m.id = :instance AND md.name = :modulename
                   
[array (
  'instance' => NULL,
  'modulename' => 'ivs',
)]
Error code: invalidrecordunknown
* line 1682 of /lib/dml/moodle_database.php: dml_missing_record_exception thrown
* line 1317 of /lib/datalib.php: call to moodle_database->get_record_sql()
* line 137 of /mod/ivs/classes/annotation.php: call to get_coursemodule_from_instance()
* line 86 of /mod/ivs/classes/UpdateService.php: call to mod_ivs\annotation->load_audio_annotation()
* line 111 of /mod/ivs/db/upgrade.php: call to mod_ivs\UpdateService->alterVideocommentTableForCommentType()
* line 934 of /lib/upgradelib.php: call to xmldb_ivs_upgrade()
* line 677 of /lib/upgradelib.php: call to upgrade_plugins_modules()
* line 1953 of /lib/upgradelib.php: call to upgrade_plugins()
* line 202 of /admin/cli/upgrade.php: call to upgrade_noncore()

!!! Datensatz kann nicht in der Datenbank gefunden werden !!!
!! SELECT cm.*, m.name, md.name AS modname 
              FROM {course_modules} cm
                   JOIN {modules} md ON md.id = cm.module
                   JOIN {ivs} m ON m.id = cm.instance
                   
             WHERE m.id = :instance AND md.name = :modulename
                   
[array (
  'instance' => NULL,
  'modulename' => 'ivs',
)]
Error code: invalidrecordunknown !!
!! Stack trace: * line 1682 of /lib/dml/moodle_database.php: dml_missing_record_exception thrown
* line 1317 of /lib/datalib.php: call to moodle_database->get_record_sql()
* line 137 of /mod/ivs/classes/annotation.php: call to get_coursemodule_from_instance()
* line 86 of /mod/ivs/classes/UpdateService.php: call to mod_ivs\annotation->load_audio_annotation()
* line 111 of /mod/ivs/db/upgrade.php: call to mod_ivs\UpdateService->alterVideocommentTableForCommentType()
* line 934 of /lib/upgradelib.php: call to xmldb_ivs_upgrade()
* line 677 of /lib/upgradelib.php: call to upgrade_plugins_modules()
* line 1953 of /lib/upgradelib.php: call to upgrade_plugins()
* line 202 of /admin/cli/upgrade.php: call to upgrade_noncore()
 !!

Moodle uses a privacy API for GDPR compliance to allow plugins to specify how they deal with user data. Your plugin stores user data in a number of tables which will need to be included in the privaci api classes.

Sites that use continuous integration processes will not be able to use your plugin because Moodle runs unit tests which check to see if all extra plugins include the privacy class.

More information on the privacy class is here:
https://docs.moodle.org/dev/Privacy_API

Connection

Usually the core fullname() function should be used instead of manually truncating firstname and lastname in your code.

The instance identification shows "0" and the player version list ist empty.
This issue is on Moodle 3.9.11 (Build: 20211108) with PHP Version 7.4.26.

backend.php

• missing login
• capability checks
• forces developer debug settings
• some weird use of $_REQUEST params without clear use of sanitisation etc.

Related to this comment

https://github.com/Ghostthinker/moodle-mod_ivs/blob/master/backend.php#L207

these functions shouldn't be there. - you shouldn't mix inline php code with functions.

settings should be defined within the ivs or mod_ivs space eg this is correct:

$settings->add(new admin_setting_heading('mod_ivs/ivssettings'

This one is incorrect

$settings->add(new admin_setting_configcheckbox('ivs_panopto_external_files_enabled'

I know you implmented travis a while back, but we've all moved to github actions (which is free) now that travis is not free anymore.

Some of the tests run by the Moodle.org plugins db can be run via github actions on each commit in your github repo. Enabling this helps you to make sure future changes to your plugin will continue to follow the guidelines.

the short version - grab this file:
https://github.com/moodlehq/moodle-plugin-ci/blob/master/gha.dist.yml
rename it as ci.yml and put into the directory .github/workflows within tyour project eg:
https://github.com/danmarsden/moodle-mod_attendance/blob/MOODLE_311_STABLE/.github/workflows/ci.yml

then on every commit you make to github it will fire off a request to run the tests and will give you traffic lights beside each commit and generate a report.

The install.xml is no longer valid and was either created for an old version of Moodle or has been handwritten.

This needs to be fixed using the Moodle xmldb editor (under admin > development > XMLDB.)

Please hit the "load" link for your plugin install.xml file in the moodle xmldb editor, and then make Moodle think there is an update to the file (easiest way to do this is to change the description of a table - add a full stop or something similar.) Then get XMLDB to "Save" the updated file which will remove all the old invalid xml from your file.

Dear devs

When installing Moodle with the mod_ivs plugin included using the cli scripts (install.php and install-database.php), the installation is aborted and I get the following error message:

Default exception handler: Unsupported redirect detected, script execution terminated Debug: 
Error code: redirecterrordetected
* line 2838 of /lib/weblib.php: moodle_exception thrown
* line 2842 of /lib/moodlelib.php: call to redirect()
* line 31 of /mod/ivs/settings.php: call to require_login()
* line 140 of /lib/classes/plugininfo/mod.php: call to include()
* line 47 of /admin/settings/plugins.php: call to core\plugininfo\mod->load_settings()
* line 8927 of /lib/adminlib.php: call to require()
* line 8953 of /lib/adminlib.php: call to admin_get_root()
* line 522 of /lib/installlib.php: call to admin_apply_default_settings()
* line 186 of /admin/cli/install_database.php: call to install_cli_database()

!!! Unsupported redirect detected, script execution terminated !!!
!! 
Error code: redirecterrordetected !!
!! Stack trace: * line 2838 of /lib/weblib.php: moodle_exception thrown
* line 2842 of /lib/moodlelib.php: call to redirect()
* line 31 of /mod/ivs/settings.php: call to require_login()
* line 140 of /lib/classes/plugininfo/mod.php: call to include()
* line 47 of /admin/settings/plugins.php: call to core\plugininfo\mod->load_settings()
* line 8927 of /lib/adminlib.php: call to require()
* line 8953 of /lib/adminlib.php: call to admin_get_root()
* line 522 of /lib/installlib.php: call to admin_apply_default_settings()
* line 186 of /admin/cli/install_database.php: call to install_cli_database()

Best regards

peta

eg:
https://github.com/Ghostthinker/moodle-mod_ivs/blob/master/classes/license/MoodleLicenseController.php#L241

Please don't initate curl_init() directly but use Moodle's own "curl" class which is a wrapper on PHP's curl functions.

Many organisations put their moodle site behind a web proxy and the internal curl wrapper takes care of this for you.

Note - this is not a blocker for approval.

please don't access raw $_GET/$_POST/$_REQUEST - you should be using the api functions optional_param and required_param with appropriate cleaning - not PARAM_RAW.

in your styles.css you define a number of generic styles that could clash with core moodle code or other locations where simliar names are used.

Moodle helpfully adds a number of classes to the body tag based on the path that you can use such as:
eg if you are have a file in mod/assign you would see the following class added to the body tag
path-mod-assign
so if you have an item with the class "filething" on the page you would target it like:

.path-mod-assign .filething {
   color: red;
}

Please make sure your css classes in styles.css are specific enough so they cannot clash with other core code.

eg "span.adminsettingsflags" in your styles.css could clash with other things - please use something like ".path-mod-ivs . span.adminsettingsflags" or similar.

Many organisations will customise their roles and you cannot guaruntee the id numbers you are using there will actually match with the correct student/teacher roles - this is not the right way to determine user access - please use capabilities rather than roles.

The best method is to create new capabilities in your plugin that are assigned to the relevant roles by default, and then check if the current user has that capability in this context.

FYI - This is a blocker for approval in the plugins db.

In your sql queries you must use placeholders instead of including vars in-line within the sql - more information here:
https://docs.moodle.org/dev/Data_manipulation_API#Placeholders

What is NOT? Regardless, it need to be used as CHAR - with single quote (as per install.xml table ivs_settings definition).

many of your files appear to be missing appropriate security checks - please review the docs here for the sorts of things you should be implementing in all files that load from the browser (including ajax related ones)
https://docs.moodle.org/dev/Security#Summary_of_the_guidelines

Please see the comments in CONTRIB-8173 for more info on this - please comment there when you have resolved this.

the plugins db description really needs to "sell" your plugin a lot better - what features does it have, what can users do with it - maybe add a few more screenshots - mention panopto support etc etc.

This one is definitely a blocker for approval

• Moodle: 3.9.19
• IVS: 2022110200
• Page: /mod/ivs/admin/admin_settings_license.php

After I clicked on "Licence" in the Admin UI, I got messages of the same two lines of code over and over:

Notice: Trying to get property 'instance_id' of non-object in /var/www/moodle_3.9.19/mod/ivs/classes/license/MoodleLicenseController.php on line 72

Notice: Trying to get property 'instance_id' of non-object in /var/www/moodle_3.9.19/mod/ivs/classes/license/MoodleLicenseController.php on line 74

Some of the tests run by the Moodle.org plugins db can be run via travis-ci on each commit in your github repo. Enabling Travis integration helps you to make sure future changes to your plugin will continue to follow the guidelines.

More information on this is here:
https://moodle.org/mod/forum/discuss.php?d=323384

but the short version:
grab this file:
https://github.com/moodlehq/moodle-plugin-ci/blob/main/.travis.dist.yml
rename it as .travis.yml and put in the root of your github directory.
Go to:
https://travis-ci.org/profile/YOUR_GITHUB_USERNAME
Flick the switch for this repo.

then on every commit you make to github it will fire off a request to travis to run the tests in .travis.yml and will give you traffic lights beside each commit and generate a report.

something else you might want to change:
in .travis.yml the default file has this line:

env:
global:

MOODLE_BRANCH=MOODLE_38_STABLE
you might want to add other branches to that list - so you might want to change it something like:

env:
global:
MOODLE_BRANCH=MOODLE_35_STABLE
MOODLE_BRANCH=MOODLE_36_STABLE
MOODLE_BRANCH=MOODLE_37_STABLE