Proposals/Done/Moodle LTI integration

Implemented in Mahara 17.04.

The University of New South Wales (UNSW) contracted Catalyst IT to design a solution for Mahara which allows to utilize Moodle's LTI support for assignment submission and that archives submitted pages on the Mahara server for accountability purposes.

UNSW favored this solution over the expansion of the existing assignment submission plugin because it would not rely on MNet. Instead, it would be built as external assignment.

The discussion of this proposed feature is at https://mahara.org/interaction/forum/topic.php?id=4676

Summary

The solution is concentrated on replacing the communication framework between Moodle and Mahara for the existing assignment submissions functionality. Modification to both Moodle and Mahara are required. On the Moodle side, LTI integration will be used to facilitate the OAuth based authentication. In OAuth parlance, Moodle is the Consumer and Mahara is the Service Provider.

In Mahara, the auth / webservice plugin will provide the basis for the OAuth authentication layer and the frame work for the web services calls made from Moodle to Mahara. The authentication settings will have an option to allow the mapping of the usernames that shall be used to identify against the LTI component. That will be either the internal Mahara username or the remote username.

The MNet authentication method does not have to be used for the LTI assignment submissions to work. Users could authenticate against any other Mahara authentication method, but might not be able to be logged in to Moodle at the same time, unless they use SAML-based authentication.

There is a role separation requirement for the API calls that differ between the tutor and student.

In a second step, submissions are archived on the Mahara server automatically.

Assignment submission

The assignment submission functions essentially like in the existing assignment submission plugin with the difference that MNet is not used but OAuth instead. The assignment submission plugin will be reworked for allow for the new authentication method.

For Mahara 1.6+: It should also be possible that collections are submitted.

Update November 2012: The assignment type should work with the new Moodle 2.3 assignment type instead of the old one.

Mahara export procedure

A submitted page will be archived under certain conditions, e.g. when an institution using Moodle decides to use the LTI assignment and / or when page submissions to groups are made and the archiving setting has been activated. The Mahara export process needs to be able to archive submitted pages after the tutor / teacher finishes grading either in Moodle or in a group that allows submissions. For Moodle it will be triggered during the API call after the evaluation of the submitted page has been finished and the page is in the process of being released back to the student.

A page is added to an export queue and not “released”, i.e. editable again, until the archiving process is successful. This queue is processed when the system has suitable resources available to perform the archiving of that page.

Any LTI-submitted page is archived automatically to ensure that no page is lost.

Mahara groups will receive an additional setting of allowing the archiving that becomes only available when page submissions are turned on.

An export queue will be implemented in Mahara so that files are processed when system resources are available. When the system has memory capacity, the system starts processing the export / archiving queue and generates Leap2A export files that are archived on the Mahara server. Once an export of a page is complete, the page is released to the user as usual.

Archived Leap2A files are stored in a special folder on the Mahara server, where all archived Leap2A files are collected.

Administrators review archiving-related system processes in the administrator interface. Thus, getting an overview of which pages have already been archived and which ones still need to be archived are displayed, and the administrators can start the archiving process manually.

Administrators download the archived Leap2A files directly from the server and also delete them there. This is more economic and less resource-intensive than downloading the files through a web interface. Administrators can also download a CSV file with the data of all successfully archived Leap2A files at any point in time before deleting them from the server.

A cron job will be implemented that takes out all listings of Leap2A files from the “Archived submissions” page that have been deleted from the server. There are going to be 2 separate administrator pages:

• Export queue: This page shows all failed and pending Leap2A exports. At the moment, the implementation will only be for portfolio submissions, but it can be re-used in future for any failed or pending exports if that functionality is revised.
• Archived submissions: This is a report of all archived submissions whose files are still on the server.

Ideas from the Moodle-Mahara Meetup

Adelaide, 8 May 2013, workshop summary

• Group submissions of assignments as is now possible in the Moodle assignment. This would be ideal with the setting up of Moodle groups / groupings automatically in Mahara.
• Display Moodle assignments in Mahara as well as the results.
• Submit an entire collection and not just individual pages.
• Have the choice to lock a page when it is being submitted; allow for re-submitting of Mahara pages / collections. I.e. allow for more formative and not only summative assessment. Submitting a Mahara page / collection could mean just to submit for the teacher to give feedback, but that doesn’t mean the page would need to be locked.
• Keep a snapshot for accountability like with other assignments that need to be archived. Potentially have options of what to keep.
• Allow for versioning of pages / collections in Mahara.
• Submit a page / collection to Moodle directly from within Mahara so students don’t have to go to the assignment in Moodle first, but can click a button in Mahara.