MoodleNet Integration

Project status

This project is complete and is included in the Moodle 3.9 release.

Project goals

This project aims to provide a workflow in Moodle core, allowing teachers to create course content by browsing and importing content from a MoodleNet instance into their Moodle site.

Introduction

MoodleNet is a content sharing platform. Users can upload content and curate collections of content. A piece of content can be either a file or a link. Instructors using Moodle, and who have access to MoodleNet, should be able to use these resources in their Moodle courses easily.

Users should be able to begin their journey in either the Moodle course (when logged in) or from MoodleNet (when browsing content there) but should always be taken back to Moodle to finalise the content creation process. In cases where the user started their journey in MoodleNet, they should be asked to select which course they want to import the resource into.

There are several ways we’d like to be able to use these resources and links in Moodle:

1. Import a resource or link into Moodle, from MoodleNet, and have the respective course modules (resource, url, others) handle the import by creating instances of themselves based on the received content.
2. Specifically when importing Moodle backups, we’d like to be able to hook into the restore process, and restore the backup into our Moodle site.

Neither of these workflows are supported in Moodle 3.8, via repositories, or via backup and restore, nor are the variants of the workflow. The concept of importing files and links into a course is currently implemented by course drag and drop, but this isn’t an API that can be used by other components. The project aims to achieve the same kind of workflow as course drag and drop, however.

Solution overview

• 3.9: Create a new admin_tool called ‘tool_moodlenet’ to handle the import workflow.
• 3.9: Create a way to extend the activity chooser footer, allowing plugins (the tool_moodlenet plugin in this case) to add html to the footer.
• 3.7 and 3.8: In addition to tool_moodlenet, provide a mod_moodlenet plugin, as a way to add MoodleNet into the legacy activity chooser.

Front end

Several pages need to be added to support the workflow: - Confirmation page (to declare the start of the import and to ask the user to confirm their intent to continue). - Course selection page (for when the user starts in MoodleNet and not in a Moodle course) - Module handler selection page (where the user chooses what course module they’d like to use to handle the incoming content)

The activity chooser should be modified to allow for plugins to extend the footer, via a new hook. This allows us to place the link to MoodleNet there, from within the admin tool, without violating any plugin communications guidelines. This will only apply to 3.9. See section below on 3.7 and 3.8 backend changes which explains how the MoodleNet activity is created in 3.7 and 3.8.

Back end

The code in tool_moodlenet (and, for 3.7 and 3.8, mod_moodlenet) should reveal more detail on the concepts discussed here, so please see there if required.

Changes for 3.9+:

Profile field

A user must enter their MoodleNet profile url as part of their Moodle profile. A profile field has been added to facilitate this.

Sending users to MoodleNet from a course: Sending the user to MoodleNet is handled by tool_moodlenet in the following way:

• The tool creates the MoodleNet endpoint URL to send the user to, based on the MoodleNet profile URL for that user. This takes the domain component of the user’s MoodleNet profile URL and appends ‘/lms/moodle/search/‘ (the default MoodleNet endpoint path) to it. It sets ‘site’, ‘course’, and ‘section’ params so that MoodleNet can temporarily store these and use them when the user selects a resource and wants to come back to Moodle.

The resulting URL must be structured as follows (i.e. MoodleNet expects this):

https://instance.moodle.net/lms/moodle/search?site=X&course=42&section=7

Where ‘X’ must be the url-encoded site address.

E.g. https://example.com/mymoodle

becomes:

https%3A%2F%2Fexample.com%2Fmymoodle

See ‘generate_mnet_endpoint()’ for more information.

• This endpoint redirection URL is supplied to core via the hook ‘custom_chooser_footer’ (i.e. tool_moodlenet_custom_chooser_footer), which is a hook allowing the footer section of the activity chooser to be extended. This hook, as implemented by the tool, returns HTML containing this link. This is added to the activity chooser footer.
• When the user clicks the ‘MoodleNet’ icon in the footer, they are redirected to MoodleNet to resource selection.

The import endpoint

Receiving the user, along with a selected resource back into Moodle is also handled by the admin tool code. An endpoint admin/tool/moodlenet/import.php exists within the tool, to handle incoming post requests from MoodleNet. This endpoint is public, and does not require a user be authenticated. Its purpose is to handle the POST request only, and redirect to a secured page (login required) via a GET call, leveraging the $wantsurl functionality of the login process. See Authentication for more details.

This endpoint REQUIRES the following parameters from MoodleNet:

• resourceurl: the URL for the resource
• resourceinfo: a JSON string containing ‘name’ and ‘summary’ information about the resource.

The following parameters can OPTIONALLY be sent:

• type: string telling Moodle how the resource should be handled. Supported options are ‘file’ and ‘link’. If not provided, Moodle will assume ‘link’ for all resources.
• course: integer id of the course to import into (if the user began the import process in a Moodle course)
• section: integer representing the course section num to import the resource into (if the user began the import process in a Moodle course)

An example of the POST payload to this endpoint is as follows:

resourceurl=https%3A%2F%2Finstance.moodle.net%2Fresource%2F64&resourceinfo=%7B%22name%22%3A%22name%22%2C%22summary%22%3A%22some+file+description%22%7D&type=file&course=1&section=4

Where:

• resourceurl corresponds to

https://instance.moodle.net/resource/64 (just an example, not a real MoodleNet URL)

• resourceinfo corresponds to the JSON string:

{“name”:”name”,”summary”:”some file description”}

Authentication

MoodleNet does not require users to be signed in to browse resources. Moodle requires users to both be signed in and to confirm their intent to import before any resource creation will occur. The POST is converted to a GET at the import endpoint, and a redirect issued to admin/tool/moodlenet/index.php, where the confirmation of import occurs. If a user is logged in to Moodle when commencing the import, they will be asked to confirm their intent on this page. If a user is not logged in to Moodle when starting the import, they will be presented will the login page, after which a redirect to the index page will occur, at which point they will need to confirm their intent to import.

Content import handlers

The index.php authenticated entry point decides whether or not the content is going to be handled as a backup, or as a file or link resource.

In the case of backups, the code just prepares the relevant information, and passed the user off to the restore process.

In the case of files and links, creation of a course module is achieved by leveraging the existing course drag and drop hooks. These hooks allow course module plugins to register their intent to handle a certain file type, or link, during a drag and drop scenario. Please note: The ways these hooks are called directly from the tool_moodlenet breaks the plugin communication guidelines and is not recommended. Ideally, a formal import workflow (a separate workflow, similar to the way restore works) would be available for plugins to leverage.

When the import is initiated, MoodleNet can provide a type parameter to Moodle, telling Moodle to treat the resource accordingly (see section above on the import endpoint). This dictates the import strategy and can be either file and link. Depending on the strategy set, the admin tool generates a list of course module plugins that support that strategy (file or link handlers). Once a module has been selected by the user during import, the code delegates how the content is displayed in the course to that specific plugin, via the dndupload_handle hook - the same functions used by drag and drop. This is all visible in admin/tool/moodlenet/classes/local/import_processor::process().

Changes for 3.7 and 3.8:

The workflow is mostly the same as with 3.9, except in one area. In addition to the admin tool, 3.7 and 3.8 versions include mod_moodlenet, which presents a dummy MoodleNet activity in the activity chooser. This module overrides the mod edit form process, and instead redirects the user to the MoodleNet endpoint. The activity chooser footer extension hook is only available in 3.9, so this approach is a workaround for that limitation.