Assignment Subtypes Combined

Introduction

This feature is part of the assignment module redevelopment project (https://docs.moodle.org/dev/Assignment). It involves creating a new module (mod_assign) that supersedes the previous one (mod_assignment). It provides all of the features of the four standard subtypes within one module (ie - you can enable file uploads, online text, notes, feedback etc).

Examples

See the use cases in the assignment redevelopment page.

This list is not exhaustive - the new assignment module will allow combinations that were not previously possible (e.g. An online assignment that also accepts file submissions)

Requirements

Core requirements

No loss of functionality from old assignment module to new assignment module
Supports Upgrade from old assignment module to new assignment module
Support for Portfolio API
Support for Plagiarism API
Full backup/restore support

Optional requirements

Allow subclasses to extend the standard assignment module (similar to the sub-types - but as a complete new module)

Pre-requisites

Moodle 2.3 required

Community bonding period

Milestones

Document proposed design and get community feedback
Decide list of settings
Decide code/file structure layout
Create mockups

Decisions

Base class

There are 3 options for creating this module. These have been proposed in the Meta-ticket (MDL-26997).

Option A

Is to create a new assignmentlib.php which contains an abstract base class for creating assignments and can be overridden by sub-classes. The new mod_assign would be an example of a module implementing the abstract base class. This would allow other custom assignment types to reuse alot of code particularly in creating the user interfaces and supporting standard features from the base class. The sub-type could then customise the implementation by disabling standard features (such as file uploads) and adding new functionality (such as an alternative submission type). The question is whether there is enough custom code in the assignment module to make this worthwhile. The most complex user interface is currently the grading page and there has been discussion of moving this into the gradebook.

Option B

Is to create the new module as a self contained module within the mod_assign folder. This would not allow people to extend it but they could copy the code into a new module and modify it as much as they like. This option is simpler but has drawbacks for maintaining forked code etc.

Option C

Although this sounds similar to the old assignment module - it is different. Allow submission plugins that can:

add additional settings to the assignment
add additional elements to the submission form
do custom saving of a submission
present a custom summary and view of a submission

These plugins would save their data in their own separate tables and only the core submission info would be saved to the submissions table. This means the code should support plugins installing and upgrading database tables on upgrade (and hooks for backup and restore).

Compared to the old assignment module, this restricts custom types to only being able to add additional ways to submit an assignment - but not modify the grading page etc.

Benefits:

All of the assignment code is in the new assign module (instead of putting an assignmentlib.php in the core lib folder)
Custom assignment submission types must create their own tables to save data instead of all abusing the data1 and data2 columns.
Custom assignment submission modules to not need to re-implement the grading interface etc.
Custom assignment modules can be used in combination with the built in assignment submission modules - e.g. an online text + online audio assignment.

Documentation

Assignment Subtypes Combined

Contents

Introduction

Examples

Requirements

Pre-requisites

Community bonding period

Milestones

Decisions

Base class

Option A

Option B

Option C

Coding period

Code repository

Milestones

File structure

Class Diagram

Mockups

Screenshots