BigBlueButton Activity Completion in Moodle 4.0

And the contributed BigBlueButtonBN plugin was finally merged into Moodle 4.0 core.

One of the most acclaimed features that is available in this plugin since version 2.4 (later backported to contrib 3.0 for Moodle 3.11 and lastly to Moodle 4.0+ core) is the support for activity completion based on the feedback received from the BigBlueButton session.

As it has been mentioned before there is no magic involved. Only the ability of these two applications to talk to each other through the plugin. But in order for this to be possible, there are some conditions to be met.

Step 1

The first and most important is that BigBlueButton must be able to process events and send them back to a third-party application. This was a feature that came enabled by default in version 2.3, but then reverted to optional in 2.4+. So, it must be manually enabled by the system administrator.

In BigBlueButton 2.5 (also 2.4 and 2.6), from the terminal, edit the bigbluebutton.properties file:

sudo vi /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties

Look up for the property defaultKeepEvents=false and change it to defaultKeepEvents=true

Restart the bbb-web component

sudo systemctl restart bbb-web

And that is all for the first step. With this, the BigBlueButton server will be enabled to process and store events once the live session has ended. Even if the meeting was not set to be recorded.

One thing to notice though is that because the script is tied to the recording processing system, the server must have recordings enabled.

Step 2

The Moodle server must be able to receive callbacks from the BigBlueButton server. This means that if it is behind a firewall and inbound traffic is not allowed, it is not going to work.

The easiest way to test this is to perform a request to the Moodle server from the console.

curl https://yourmoodleserve.yourdomain.com

Note that the Web Server where Moodle is installed should also be able to process `HTTP:Authorization` headers.

While this should normally not be a problem, at the time this article was written, it was reported that Apache by default did not pass the Authorization header through to FastCGI scripts. Also that various Apache modules (such as mod_proxy) strip the Authorization header, usually for “security reasons”.

In those cases it may be necessary to apply settings that are specific for the modules causing the problem or workaround by adding rewritting rules to the same. That may be done at the Web Server level, or for those without access to modify its configuration files, by adding those changes to .htaccess in the root directory of Moodle.

In Apache the rewriting rule would look like this:

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

Note that there are not known issues with Nginx and during the tests performed everything worked out of the box.

It is also known that some firewalls may remove that header for the same reasons. In these cases that rule should be modified and allow the Web Server itself to deal with the matter.

Step 3.

Finally, in Moodle, the cron jobs must be enabled and the plugin must have enabled the option Register live sessions.

For enabling cron jobs system administrators need to follow the steps in the official documentation.

And enabling the feature in the plugin from Plugin Settings in Moodle.

Now, in terms of how to use this new feature, it is really very simple.

When creating or editing the Activity in Moodle, there is a new option ‘Show activity as complete when conditions are met’. If selected a new group of settings will be displayed.

The basic completion is based on the time students spend in the live session, but it is also possible to make it based on participation.

If the conditions are meet, the completion is registered for the students.

Enjoy it!

Known issues:
There are some bugs on this feature that ware found after the release of Moodle 4.0. The patch can be found here and should be merged and released as 4.0.3 soon.