assignment->name. "_");. in /mod/assignment/type/upload/ assignment.class.php and /mod/assignment/type/uploadsingle/assignment.class. php. This will ensure any characters that are not valid in a filename are removed/ replaced. Dec 10, 2010 Turning off "Upload a single file" Assignment type in Moodle. Among the various things we're doing for UNE's $CFG->assignment_hide_uploadsingle = true;. Then tweak mod/assignment/lib.php as per the commit at https://github.com/une/ moodle/commit/cf89f14ffc36cae22175874f6f737f4e773cfd74.">
Skip to content

Upload Uploadsingle Type Assignment Mod

Important

To upload feedback files you will need to zip them first AND they must have the correct naming convention (all files starting with for example ). The zip package should only contain feedback files that you want returned to students. All feedback files within a .zip package will be returned to the student regardless of whether they have been changed since downloading. Therefore, delete any unwanted feedback files from the zip package being returned to FLO.

Any feedback files with the same name will overwrite any existing files.

Do not include the grading worksheet in this zip. Uploading the grading worksheet is a separate process.

If uploading a feedback file or marked assignment for a single student, it is not necessary to zip the file first.  For individual upload instructions please see the Gateway entry Upload a Feedback file for a single student

Steps

To create the zip file:

    1. Select the files you wish to upload

    2. Right-click on one of the files and choose Send to, then Compressed (zipped) folder. The zipped folder will by default use the name of one of the students' files. You can rename this if you wish.



    3. In FLO, click on the assignment link and then click View/Grade all submissions

    4. Select Upload marked assignments and feedback files from the Grading action menu (top of the screen)
    5. In this screen, you can use either the Choose a file... button to navigate to your file or simply drag and drop it into the box. The file name will appear in the box once it has been added
    6. Click the Import feedback file(s) button

    7. You will be provided with a detailed list of the file changes being made. Here you can see that the summary of files added. Click Confirm
    8. You will see a summary of how many users have had feedback updated, how many existing feedback files have been updated and how many files were added.
    9. Click Continue to go back to the grading screen where you will see the feedback files have been added. Note: Any feedback files with the same name will overwrite any existing files.

You might also be interested in…

Introduction

This page gives an overview of assignment submission plugims within the assignment module.

Overview of an assignment submission plugin

An assignment submission plugin is used to display custom form fields to a student when they are editing their assignment submission. It also has full control over the display the submitted assignment to graders and students. Plugins participate in all assignment features including backup/restore, upgrades from 2.2, offline grading, group assignments and blind marking.

  • An assignment submission plugin can add settings to the module settings page.

  • An assignment submission plugin can show a summary of the submission to students and graders.

  • An assignment submission plugin can add form fields to the student submission page.

History

Assignment submission plugins were added with the assignment module rewrite for Moodle 2.3.

Template

A great example is the "onlinetext" submission plugin included with Moodle core.

File structure

The files for a custom submission plugin sit under "mod/assign/submission/<pluginname>". A plugin should not include any custom files outside of it's own plugin folder.

Note: The plugin name should be no longer than 11 characters - this is because the database tables for a submission plugin must be prefixed with "assignsubmission_" + pluginname (17 chars + X) and the table names can be no longer than 28 chars (thanks oracle). If a plugin requires multiple database tables, the plugin name will need to be shorter to allow different table names to fit under the 28 character limit.

All examples in this document exclude the required copyright and license information from source files for brevity.

version.php

To start with we need to tell Moodle the version information for our new plugin so that it can be installed and upgraded correctly. This information is added to version.php as with any other type of Moodle plugin. The component name must begin with "assignsubmission_" to identify this as a submission plugin.

See version.php for more information.

defined('MOODLE_INTERNAL') || die(); $plugin->version = 2012112900; $plugin->requires = 2012112900; $plugin->component = 'assignsubmission_file';

settings.php

The settings file allows us to add custom settings to the system wide configuration page for our plugin.

All submission settings should be named 'assignsubmission_pluginname/settingname' in order for the setting to be associated with the plugin.

All submission plugins should include one setting named 'default' to indicate if the plugin should be enabled by default when creating a new assignment.

This example from the submission_file plugin also checks to see if there is a maxbytes setting for this moodle installation and if found, it adds a new admin setting to the settings page. The name of the setting should begin with the plugin component name ("assignsubmission_file") in this case. The strings are specified in this plugins language file.

// Note: This is on by default. $settings->add(new admin_setting_configcheckbox('assignsubmission_file/default', new lang_string('default', 'assignsubmission_file'), new lang_string('default_help', 'assignsubmission_file'), 1)); if (isset($CFG->maxbytes)) { $name = new lang_string('maximumsubmissionsize', 'assignsubmission_file'); $description = new lang_string('configmaxbytes', 'assignsubmission_file'); $element = new admin_setting_configselect('assignsubmission_file/maxbytes', $name, $description, 1048576, get_max_upload_sizes($CFG->maxbytes)); $settings->add($element); }

lang/en/submission_pluginname.php

The language file for this plugin must have the same name as the component name (e.g. "submission_file.php"). It should at least define a string for "pluginname". For example:

$string['pluginname'] = 'Awesome submissions';

db/access.php

This is where any additional capabilities are defined if required. This file can be omitted if there are no capabilities added by the plugin.

See Activity_modules#access.php for more information.

$capabilities = array( 'assignsubmission/dungeon:master' => array( 'riskbitmask' => RISK_XSS, 'captype' => 'write', 'contextlevel' => CONTEXT_COURSE, 'archetypes' => array( 'editingteacher' => CAP_ALLOW, 'manager' => CAP_ALLOW ), 'clonepermissionsfrom' => 'moodle/course:manageactivities' ), );

db/upgrade.php

This is where any upgrade code is defined.

See Activity_modules#upgrade.php for more infomation.

function xmldb_submission_file_upgrade($oldversion) { global $CFG, $DB, $OUTPUT; $dbman = $DB->get_manager(); if ($oldversion < 2012091800) { // Put upgrade code here // Savepoint reached. upgrade_plugin_savepoint(true, 2012091800, 'assignsubmission', 'file'); } return true; }

db/install.xml

This is where any database tables required to save this plugins data are defined. File submissions define a table that links to submission and contains a column to record the number of files.

<?xml version="1.0" encoding="UTF-8" ?> <XMLDB PATH="mod/assign/submission/file/db" VERSION="20120423" COMMENT="XMLDB file for Moodle mod/assign/submission/file" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../../../lib/xmldb/xmldb.xsd" > <TABLES> <TABLE NAME="assignsubmission_file" COMMENT="Info about file submissions for assignments"> <FIELDS> <FIELD NAME="id" TYPE="int" LENGTH="10" NOTNULL="true" SEQUENCE="true"/> <FIELD NAME="assignment" TYPE="int" LENGTH="10" NOTNULL="true" DEFAULT="0" SEQUENCE="false"/> <FIELD NAME="submission" TYPE="int" LENGTH="10" NOTNULL="true" DEFAULT="0" SEQUENCE="false"/> <FIELD NAME="numfiles" TYPE="int" LENGTH="10" NOTNULL="true" DEFAULT="0" SEQUENCE="false" COMMENT="The number of files the student submitted."/> </FIELDS> <KEYS> <KEY NAME="primary" TYPE="primary" FIELDS="id" COMMENT="The unique id for this submission info."/> <KEY NAME="assignment" TYPE="foreign" FIELDS="assignment" REFTABLE="assign" REFFIELDS="id" COMMENT="The assignment instance this submission relates to"/> <KEY NAME="submission" TYPE="foreign" FIELDS="submission" REFTABLE="assign_submission" REFFIELDS="id" COMMENT="The submission this file submission relates to."/> </KEYS> </TABLE> </TABLES> </XMLDB>

db/install.php

This example is from the submission_comments plugin. It shows how to run custom code on installation of the plugin. In this case it makes the comments plugin the last of the three submission plugins installed by default.

/** * Code run after the plugin database tables have been created. */ function xmldb_assignsubmission_comments_install() { global $CFG, $DB, $OUTPUT; // do the install require_once($CFG->dirroot . '/mod/assign/locallib.php'); // set the correct initial order for the plugins $assignment = new assignment(); $plugin = $assignment->get_submission_plugin_by_type('comments'); if ($plugin) { $plugin->move('down'); $plugin->move('down'); } return true; }

locallib.php

This is where all the functionality for this plugin is defined. We will step through this file and describe each part as we go.

class assign_submission_file extends assign_submission_plugin {

All submission plugins MUST define a class with the component name of the plugin that extends assign_submission_plugin.

get_name()

public function get_name() { return get_string('file', 'assignsubmission_file'); }

Get name is abstract in submission_plugin and must be defined in your new plugin. Use the language strings to make your plugin translatable.

get_settings()

The "get_settings" function is called when building the settings page for the assignment. It allows this plugin to add a list of settings to the form. Notice that the settings are prefixed by the plugin name which is good practice to avoid conflicts with other plugins.

save_settings()

The "save_settings" function is called when the assignment settings page is submitted, either for a new assignment or when editing an existing one. For settings specific to a single instance of the assignment you can use the assign_plugin::set_config function shown here to save key/value pairs against this assignment instance for this plugin.

get_form_elements()

The get_form_elements function is called when building the submission form. It functions identically to the get_settings function except that the submission object is available (if there is a submission) to associate the settings with a single submission. This example also shows how to use a filemanager within a submission plugin. The function must return true if it has modified the form otherwise the assignment will not include a header for this plugin.

save()

The "save" function is called to save a user submission. The parameters are the submission object and the data from the submission form. This example calls file_postupdate_standard_filemanager to copy the files from the draft file area to the filearea for this submission, it then uses the event api to trigger an assessable_file_uploaded event for the plagiarism api. It then records the number of files in the plugin specific "assignsubmission_file" table.

get_files()

If this submission plugin produces one or more files, it should implement "get_files" so that the portfolio API can export a list of all the files from all of the plugins for this assignment submission. This is also used by the offline grading feature in the assignment.

view_summary()

The view_summary function is called to display a summary of the submission to both markers and students. It counts the number of files submitted and if it is more that a set number, it only displays a count of how many files are in the submission - otherwise it uses a helper function to write the entire list of files. This is because we want to keep the summaries really short so they can be displayed in a table. There will be a link to view the full submission on the submission status page.

view()

The view function is called to display the entire submission to both markers and students. In this case it uses the helper function in the assignment class to write the list of files.

can_upgrade()

public function can_upgrade($type, $version) { $uploadsingle_type ='uploadsingle'; $upload_type ='upload'; if (($type == $uploadsingle_type || $type == $upload_type) && $version >= 2011112900) { return true; } return false; }

The can_upgrade function is used to identify old "Assignment 2.2" subtypes that can be upgraded by this plugin. This plugin supports upgrades from the old "upload" and "uploadsingle" assignment subtypes.

upgrade_settings()

This function is called once per assignment instance to upgrade the settings from the old assignment to the new mod_assign. In this case it sets the maxbytes, maxfiles and alwaysshowdescription configuration settings.

upgrade()

The "upgrade" function upgrades a single submission from the old assignment type to the new one. In this case it involves copying all the files from the old filearea to the new one. There is a helper function available in the assignment class for this (Note: the copy will be fast as it is just adding rows to the files table). If this function returns false, the upgrade will be aborted and rolled back.

get_editor_fields()

public function () { return array('onlinetext' => get_string('pluginname', 'assignsubmission_comments')); }

This example is from assignsubmission_onlinetext. If the plugin uses a text-editor it is ideal if the plugin implements "get_editor_fields". This allows the portfolio to retrieve the text from the plugin when exporting the list of files for a submission. This is required because the text is stored in the plugin specific table that is only known to the plugin itself. If a plugin supports multiple text areas it can return the name of each of them here.

get_editor_text()

This example is from assignsubmission_onlinetext. If the plugin uses a text-editor it is ideal if the plugin implements "get_editor_text". This allows the portfolio to retrieve the text from the plugin when exporting the list of files for a submission. This is required because the text is stored in the plugin specific table that is only known to the plugin itself. The name is used to distinguish between multiple text areas in the one plugin.

get_editor_format()

This example is from assignsubmission_onlinetext. For the same reason as the previous function, if the plugin uses a text editor, it is ideal if the plugin implements "get_editor_format". This allows the portfolio to retrieve the text from the plugin when exporting the list of files for a submission. This is required because the text is stored in the plugin specific table that is only known to the plugin itself. The name is used to distinguish between multiple text areas in the one plugin.

is_empty()

If a plugin has no submission data to show - it can return true from the is_empty function. This prevents a table row being added to the submission summary for this plugin. It is also used to check if a student has tried to save an assignment with no data.

get_file_areas()

A plugin should implement get_file_areas if it supports saving of any files to moodle - this allows the file areas to be browsed by the moodle file manager.

copy_submission()

Since Moodle 2.5 - a students submission can be copied to create a new submission attempt. Plugins should implement this function if they store data associated with the submission (most plugins).

format_for_log()

The format_for_log function lets a plugin produce a really short summary of a submission suitable for adding to a log message.

delete_instance()

The delete_instance function is called when a plugin is deleted. Note only database records need to be cleaned up - files belonging to fileareas for this assignment will be automatically cleaned up.

lib.php

This file is the entry point to many standard Moodle APIs for plugins. An example is that in order for a plugin to allow users to download files contained within a filearea belonging to the plugin, they must implement the componentname_pluginfile function in order to perform their own security checks.

See File_API for more information. Example:

function assignfeedback_file_pluginfile($course, $cm, context $context, $filearea, $args, $forcedownload) { global $USER, $DB; if ($context->contextlevel != CONTEXT_MODULE) { return false; } require_login($course, false, $cm); $itemid = (int)array_shift($args); $record = $DB->get_record('assign_grades', array('id'=>$itemid), 'userid,assignment', MUST_EXIST); $userid = $record->userid; if (!$assign = $DB->get_record('assign', array('id'=>$cm->instance))) { return false; } if ($assign->id != $record->assignment) { return false; } // Check is users feedback or has grading permission. if ($USER->id != $userid and !has_capability('mod/assign:grade', $context)) { return false; } $relativepath = implode('/', $args); $fullpath = "/{$context->id}/assignfeedback_file/$filearea/$itemid/$relativepath"; $fs = get_file_storage(); if (!$file = $fs->get_file_by_hash(sha1($fullpath)) or $file->is_directory()) { return false; } // Download MUST be forced - security! send_stored_file($file, 0, 0, true); }

Useful classes

A submission plugin has access to a number of useful classes in the assignment module. See the phpdocs (or the code) for more information on these classes.

assign_plugin

This abstract class is the base class for all assignment plugins (feedback or submission plugins).

assign_submission_plugin

This is the base class all assignment submission plugins must extend. It contains a small number of additional function that only apply to submission plugins.

assign

This is the main class for interacting with the assignment module.

It contains public functions that are useful for listing users, loading and updating submissions, loading and updating grades, displaying users etc.

Other features

Add calendar events

Moodle 3.1


From Moodle 3.1 onwards, submission plugins can add events to the Moodle calendar without side effects. These will be hidden and deleted in line with the assignment module. For example:

// Add release date to calendar $calendarevent = new stdClass(); $calendarevent->name = get_string('calendareventname', 'assignsubmission_something'); $calendarevent->description = get_string('calendareventdesc', 'assignsubmission_something'); $calendarevent->courseid = $courseid; $calendarevent->groupid = 0; $calendarevent->userid = $userid; $calendarevent->modulename = 'assign'; $calendarevent->instance = $instanceid; $calendarevent->eventtype = 'something_release'; // For activity module's events, this can be used to set the alternative text of the event icon. Set it to 'pluginname' unless you have a better string. $calendarevent->timestart = $releasedate; $calendarevent->visible = true; $calendarevent->timeduration = 0; calendar_event::create($calendarevent);

This code should be placed in the "save_settings()" method of your assign_submission_plugin class.