MoodleDocs - User contributions [en]

Submissions Library

2015-06-22T18:36:38Z

Nixo: /* Someone tries to download a file from submissionplugin_file */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]

See also: [[#Accessing files]]

TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===
A main plugin class should be calles submissionplugin_<pluginnname> and it should be inherited from abstract class submissionplugin.

TODO: add detailed description on methods plugin must implement.

== Backup/restore ==
The submission must be a part of activity module instances.

== What else to consider ==

== See also ==
* [[Assign submission plugins]]
* [[Advanced grading methods]] - if we have a multiple grading areas, each of those area may require a submissions.

Submissions Library

2015-06-22T18:35:01Z

Nixo: /* See also */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===
A main plugin class should be calles submissionplugin_<pluginnname> and it should be inherited from abstract class submissionplugin.

TODO: add detailed description on methods plugin must implement.

== Backup/restore ==
The submission must be a part of activity module instances.

== What else to consider ==

== See also ==
* [[Assign submission plugins]]
* [[Advanced grading methods]] - if we have a multiple grading areas, each of those area may require a submissions.

Submissions Library

2015-06-22T18:34:45Z

Nixo: /* See also */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===
A main plugin class should be calles submissionplugin_<pluginnname> and it should be inherited from abstract class submissionplugin.

TODO: add detailed description on methods plugin must implement.

== Backup/restore ==
The submission must be a part of activity module instances.

== What else to consider ==

== See also ==
* [[Assign submission plugins]]
* [[Advanced Grading Methods]] - if we have a multiple grading areas, each of those area may require a submissions.

Submissions Library

2015-06-22T18:15:52Z

Nixo: /* Backup/restore */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===
A main plugin class should be calles submissionplugin_<pluginnname> and it should be inherited from abstract class submissionplugin.

TODO: add detailed description on methods plugin must implement.

== Backup/restore ==
The submission must be a part of activity module instances.

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:14:16Z

Nixo: /* Submission plugin development */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===
A main plugin class should be calles submissionplugin_<pluginnname> and it should be inherited from abstract class submissionplugin.

TODO: add detailed description on methods plugin must implement.

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:12:54Z

Nixo: /* Accessing files */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===
The activity module should be responsible of giving access to files stored by submission plugins, because only activity module can interpret area and itemid correctly.

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:10:39Z

Nixo: /* How "File submission" plugin stores files */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===
File submission plugin stores all files at file areas identified by:
* context — activity context (from submissions_bindings)
* component name — submissionplugin_file
* area type — submissionplugin_file_<area> (<area> from submissions_bindings)
* itemid — submission instance id.

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:08:22Z

Nixo: /* Course module deletion */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]

submission::delete_all_for_context(...) call should be added to course_delete_module(...) function.

Note: all associated files will be deleted when course_delete_module(...) function calls deletion of all files associated with the module's context. Perhaps submission plugins should not rely on this.

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:03:31Z

Nixo: /* Teacher views student's submission */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]
TODO: add more details

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]
TODO: add more details

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:03:19Z

Nixo: /* Student makes a submission */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]
TODO: add more details

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]
TODO: add more details

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T18:03:06Z

Nixo: /* Course module deletion */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====
[[{{ns:file}}:submissionlib delcoursemod.png|200px|thumb|none|UML Sequence Diagram: course module deletion]]
TODO: add more details

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

File:submissionlib delcoursemod.png

2015-06-22T18:02:44Z

Nixo:

Submissions Library

2015-06-22T18:02:08Z

Nixo: /* Someone tries to download a file from submissionplugin_file */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]

==== Someone tries to download a file from submissionplugin_file ====
[[{{ns:file}}:submissionlib accessfile.png|200px|thumb|none|UML Sequence Diagram: someone tries to download a file]]
TODO: add more details

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

File:submissionlib accessfile.png

2015-06-22T18:01:29Z

Nixo:

Submissions Library

2015-06-22T18:01:02Z

Nixo: /* Teacher views student's submission */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]

==== Teacher views student's submission ====
[[{{ns:file}}:submissionlib teacher.png|200px|thumb|none|UML Sequence Diagram: teacher views student's submission]]

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

File:submissionlib teacher.png

2015-06-22T18:00:29Z

Nixo:

Submissions Library

2015-06-22T17:59:53Z

Nixo: /* General workflow details */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|none|UML Sequence Diagram: student makes a submission]]

==== Teacher views student's submission ====

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T17:58:49Z

Nixo: /* Student makes a submission */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====
[[{{ns:file}}:submissionlib student.png|200px|thumb|left|UML Sequence Diagram: student makes a submission]]

==== Teacher views student's submission ====

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

File:submissionlib student.png

2015-06-22T17:57:08Z

Nixo:

Submissions Library

2015-06-22T17:48:18Z

Nixo:

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====

==== Teacher views student's submission ====

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

== See also ==

Submissions Library

2015-06-22T17:47:58Z

Nixo: /* Backup/restore */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====

==== Teacher views student's submission ====

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== What else to consider ==

Submissions Library

2015-06-22T17:46:19Z

Nixo: /* API for activity modules */

== Project goal ==
Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed.

== Project scope ==
A library providing API for activity module submission types support implementation. Actual proposition is to make assignsubmission plugins system-level.

The existing modules requiring submissions (Assignment, Workshop) should use this library.

== Relevant tracker issues ==
# MDL-47344 - Allow usage of submission methods in other plugins

== Use cases ==
# Assignment: no comment.
# Workshop: uses submissions but it's another code doing the same.
# Lesson: as well as questions the submissions could be used at lessons for a small tasks. For example, a task at the end of lesson about MS Paint: draw an your dream house, save it and upload.
# Community module: for example, [[POAS Assignment development|Assignment with individual tasks]] could not re-implement all existing submission types.
# Non-mod usage? If there is no such cases this library should only work with activity modules.

== Database schema ==

=== submissions_bindings ===
Identifies all connected submission plugins to an activity modules.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''context''
| bigint
|
| Activity context.
|-
| area
| varchar(100)
|
| An area within activity module. A module may have a few.
|-
| method
| varchar(100)
|
| Submission plugin name. It is considered that the plugin is activated in these area of these activity module instance.
|}

=== submissions_pluginconfig ===
Stores plugins configuration.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| option
| varchar(100)
|
| Plugin setting name.
|-
| value
| text
|
| Setting value.
|}

=== submissions_instances ===
Identifies all submissions. A data associated with the submission is stored by plugin.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''binding''
| bigint
|
| Activated plugin. Points to submissions_bindings record.
|-
| itemid
| bigint
| null
| Identifies an element within area. For example, answer or user id.
|-
| timecreated
| bigint
| 0
| When the submission was created.
|-
| timemodified
| bigint
| 0
| Latest submission modification time.
|-
| status
| int
| 0
| Draft (default), Latest, Archived.
|}

=== submissionplugin_onlinetext ===
This is a table example for "Online text" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| onlinetext
| text
|
| Actual submission data.
|-
| onlineformat
| int
| 0
| Text format.
|}

=== submissionplugin_file ===
This is a table example for "File submission" plugin. This table is not a part of library.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered.
|-
| ''submissioninstance''
| bigint
|
| Point to submission from submissions_instances table.
|-
| numfiles
| bigint
|
| Number of submitted files.
|}

== How it works ==

=== API for activity modules ===

==== Activity instance settings form ====
In order to add a plugin settings elements on activity settings page the following method of moodleform_mod should be used:
<code php>$this->standard_submission_coursemodule_elements();</code>

==== Displaying a submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

First, a submission_instance object should be retrieved.
<code php>$submissioninstance = $submission->get_submission_instance($itemid);</code>

Next, it can be displayed.
<code php>if ($submissioninstance) {
$submissioninstance->display();
// or
$html = $submissioninstance->render();
}</code>

==== Displaying submission form ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

A special method should be used to add elements on submission form. A previous submission can be loaded by specifying $baseitemid.
<code php>$submission->add_submission_form_elements($mform, $baseitemid);</code>

==== Save/update submission ====
Activity module should access the submissions using a submission class.
<code php>$submission = new submission($context, $area);</code>

To save or update the submission a special method should be used. It accepts submitted form data as its only argument.
<code php>$submission->save($formdata);</code>

==== Delete submission ====
All submissions associated with the activity module instance can be deleted by using the following static method:
<code php>submission::delete_all_for_context($context);</code>

Individual submissions can be deleted this way:
<code php>$submission = new submission($context, $area);
$submission->delete($itemid);</code>

=== General workflow details ===

==== Student makes a submission ====

==== Teacher views student's submission ====

==== Someone tries to download a file from submissionplugin_file ====

==== Course module deletion ====

=== How "File submission" plugin stores files ===

=== Accessing files ===

=== Submission plugin development ===

== Backup/restore ==

== Backup/restore ==

Submissions Library

2015-06-22T17:34:42Z

Nixo: /* How it works */

Submissions Library

2015-06-22T17:25:45Z

Nixo: /* Use cases */

Submissions Library

2015-06-22T11:33:30Z

Nixo: /* submissionplugin_file */

Submissions Library

2015-06-22T11:32:25Z

Nixo: /* submissionplugin_onlinetext */

Submissions Library

2015-06-22T11:26:52Z

Nixo: /* submissions_instances */

Submissions Library

2015-06-22T11:19:23Z

Nixo: /* submissions_pluginconfig */

Submissions Library

2015-06-22T11:15:40Z

Nixo: /* Database schema */

Submissions Library

2015-06-22T11:07:47Z

Nixo: /* Database schema */

Submissions Library

2015-06-22T10:56:00Z

Nixo: Created page with "== Project goal == Make activity module developers (not only Assignment developers) able to use submission types: both standard and community-developed. == Project scope ==..."

VSTU projects

2015-06-22T10:26:07Z

Nixo:

==Lead: Sychev Oleg Aleksandrovich==
Senior Lecturer of POAS (Software Engineering) department

===Core patches===
# [[Categories editing interface improvment|Improvment of editing interface for category list]]. Moving category anywhere should require only one page reload. Developers: Sychev Oleg, Shkarupa Alex. Status: waiting reviewing!
# [[Javascript-interface for repeat_elements function|Javascript-interface for repeat_elements function]] - adding new blanks to the form shoudn't require page reloads.
# [[Forum thread subscription|Forum thread subscription]] - a long standing request to be able to subscript only to the thread, not whole forum.
# [[AJAX mod editing|Editing course modules without reloading ]] - adding/editing activities(resources) in AJAX mode without page reloads.
# [[Exporting/importing several question categories at once|Exporting/importing several question categories at once]] - changing the interface of exporting question categories.
# [[Capturing and sending to the server selection user piece of text on the web page|Capturing and sending to the server selection user piece of text on the web page]] - TODO.
# [[Save category description in Moodle XML import/export|Save category description in Moodle XML import/export]] - TODO.

===Activity modules===
# [[Assignment development|New assignment-replacement module]] with support for individual tasks (with custom fields), several grading criterions, automatic graders etc.
# [[Subcourse module improvments|Subcourse module improvments]] - improve Subcourse module to get rid of buggy Metacourses and make it actually useful.
# [[Question-lesson link|A proposition how to link question engine with lesson module]] - adding only two simple functions to the question definition we could create ideal connection with the lesson module, and not only it.

===Question types===
# [https://docs.moodle.org/en/Preg_question_type Preg question type] - regular expression question type, developed on more solid algorithmic basis than regex one.
# [[Auto-feedback shortanswer question|Auto-feedback shortanswer question "CorrectWriting" project]] and [https://docs.moodle.org/en/question/type/correctwriting user documentation] for shortanswer question which could be able to detect typos and misplaced, missing or extra words and give appropriate feedback.

===Question behaviours===
# [https://docs.moodle.org/dev/Hinting_question_behaviours(VSTU) Hinting behaviours] - behaviours that would help standartise hinting from each qtype.

===Blocks===
# [[Linked activities|Linked activities]] to allow editing properties of multiple activities at once.
# [https://docs.moodle.org/en/Formal_Languages_Block Formal languages block] which allows to scan (tokenize) and (future) parse text in several languages (currently english, C, C++).
# [https://docs.moodle.org/en/Auto_role_assignment_block Auto role assignment block] is useful to temporary restrict (or enhance) user abilities while doing something.
# [https://docs.moodle.org/en/Supervised_block Supervised block] is much better than IP filter+time control if you want students to be able to do something only under teacher supervision. Supports out of the box restricting quizzes for supervized sessions only, but very powerful when combined with previous one (auto role assignment), allowing any permission changes.

===Libraries===
# [[Auto-backup library|Auto-backup library]] - adding very small information to install.xml files it is possible to automate many tedious tasks of programming backup/restore for the plugins.
# [[Submissions Library]] - make assignsubmission plugins usable by any activity module.

===Grading Methods===
# [[Meta AGM]] - grading method which allows usage of multiple AGM's with one activity at once.

Meta AGM

2015-03-02T15:24:49Z

Nixo: Fixed some grammar

== General information ==
'''Project goal:''' to be able to use multiple [[Advanced grading methods]] at one grading area.

'''Project scope.''' This project does not change the AGM internals and its API. Meta AGM is a grading method, the form of which is a number of another AGMs.

== Use cases ==
In examples below 'rubric' and 'criterial' grading methods were used. Criterial is a work-in-progress method which allows teacher to define a form with a number of numerical fields, checkboxes, etc.

=== 1. Assessment of student's program on the course of high-level programming basics ===
There are lot of aspects of checking the quality of program which is developed by student: efficiency, code style compliance, lab activity protocol... So we need a various grading method types to develop a set of criteria allowing us to assess all the aspects described in one assignment module.

TODO: defined AGM example

== Implementation ==
This module allows a teacher to define several metacriteria and define different grading methods in it. The teacher defines metacriteria by himself.

While AGM design allows us to have only one active grading method in one gradeable area, we can create more areas (fake areas actually) for the same context. We call it 'metacriteria'. It's safe because any other modules uses MODULENAME_grading_areas_list() to list the areas, not DB query.

=== How it works ===
[[image:metaagm-sd.png|400px|thumb|none|UML sequence diagram of how the teacher defines the metacriteria and what happens in DB during this process.]]

1.1 ''Get the metacriteria list:'' list of areas for current contextid and module will be returned (except the area which Meta AGM is defined in).

3.2.1.1: A new record with fake area for current contextid and module will be inserted to grading_areas table and a record to gradeform_metaagm_areas (see below).

=== DB schema ===
[[File:metaagm-erd.png]]

==== gradeform_metaagm_areas ====
Each metacriterion additionally listed in this table. There are weight and name fields are important. Teacher can define a human-readable name for each metacriterion and a weight of grade for this metacriterion.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered
|-
| '''areaid'''
| bigint
|
| The gradeable area for Meta AGM.
|-
| '''subareaid'''
| bigint
|
| The gradeable area for metacriterion.
|-
| weight
| float
| 1.0
| Weight for grade of this metacriterion.
|-
| name
| varchar(255)
|
| Human-readable name of this metacriterion.
|}

=== Backup/Restore ===
TODO

== See also ==
* [[Advanced grading methods]]
* [[Advanced grading API]]

Meta AGM

2014-12-08T06:54:22Z

Nixo: /* DB schema */

== General information ==
'''Project goal:''' to be able to use multiple [[Advanced grading methods]] at one grading area.

'''Project scope.''' This project does not change the AGM internals and its API. Meta AGM is a grading method, the form of which is a number of another AGMs.

== Use cases ==
In examples below 'rubric' and 'criterial' grading methods were used. Criterial is a work-in-progress method which allows teacher to define a form with a number of numerical fields, checkboxes, etc.

=== 1. Assessment of student's program on the course of high-level programming basics ===
There are lot of aspects of checking the quality of program which is developed by student: efficiency, code style compliance, lab activity protocol... So we need a various grading method types to develop a set of criterions allowing us to assess all the aspects described in one assignment module.

TODO: defined AGM example

== Implementation ==
This module allows a teacher to define several metacriterions and define different grading methods in it. The teacher defines metacriterions by himself.

While AGM design allows us to have only one active grading method in one gradeable area, we can create more areas (fake areas actually) for the same context. We call it 'metacriterions'. It's safe because any other modules uses MODULENAME_grading_areas_list() to list the areas, not DB query.

=== How it works ===
[[image:metaagm-sd.png|400px|thumb|none|UML sequence diagram of how the teacher defines the metacriterions and what happens in DB during this process.]]

1.1 ''Get the metacriterions list:'' list of areas for current contextid and module will be returned (except the area which Meta AGM is defined in).

3.2.1.1: A new record with fake area for current contextid and module will be inserted to grading_areas table and a record to gradeform_metaagm_areas (see below).

=== DB schema ===
[[File:metaagm-erd.png]]

==== gradeform_metaagm_areas ====
Each metacriterion additionally listed in this table. There are weight and name fields are important. Teacher can define a human-readable name for each metacriterion and a weight of grade for this metacriterion.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered
|-
| '''areaid'''
| bigint
|
| The gradeable area for Meta AGM.
|-
| '''subareaid'''
| bigint
|
| The gradeable area for metacriterion.
|-
| weight
| float
| 1.0
| Weight for grade of this metacriterion.
|-
| name
| varchar(255)
|
| Human-readable name of this metacriterion.
|}

=== Backup/Restore ===
TODO

== See also ==
* [[Advanced grading methods]]
* [[Advanced grading API]]

File:metaagm-erd.png

2014-12-08T06:48:44Z

Nixo: Nixo uploaded a new version of "File:metaagm-erd.png"

Meta AGM

2014-11-30T22:28:31Z

Nixo:

== General information ==
'''Project goal:''' to be able to use multiple [[Advanced grading methods]] at one grading area.

'''Project scope.''' This project does not change the AGM internals and its API. Meta AGM is a grading method, the form of which is a number of another AGMs.

== Use cases ==
In examples below 'rubric' and 'criterial' grading methods were used. Criterial is a work-in-progress method which allows teacher to define a form with a number of numerical fields, checkboxes, etc.

=== 1. Assessment of student's program on the course of high-level programming basics ===
There are lot of aspects of checking the quality of program which is developed by student: efficiency, code style compliance, lab activity protocol... So we need a various grading method types to develop a set of criterions allowing us to assess all the aspects described in one assignment module.

TODO: defined AGM example

== Implementation ==
This module allows a teacher to define several metacriterions and define different grading methods in it. The teacher defines metacriterions by himself.

While AGM design allows us to have only one active grading method in one gradeable area, we can create more areas (fake areas actually) for the same context. We call it 'metacriterions'. It's safe because any other modules uses MODULENAME_grading_areas_list() to list the areas, not DB query.

=== How it works ===
[[image:metaagm-sd.png|400px|thumb|none|UML sequence diagram of how the teacher defines the metacriterions and what happens in DB during this process.]]

1.1 ''Get the metacriterions list:'' list of areas for current contextid and module will be returned (except the area which Meta AGM is defined in).

3.2.1.1: A new record with fake area for current contextid and module will be inserted to grading_areas table and a record to gradeform_metaagm_areas (see below).

=== DB schema ===
[[File:metaagm-erd.png]]

==== gradeform_metaagm_areas ====
Each metacriterion additionally listed in this table. There are weight and name fields are important. Teacher can define a human-readable name for each metacriterion and a weight of grade for this metacriterion.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered
|-
| '''areaid'''
| bigint
|
| The gradeable area for metacriterion.
|-
| weight
| float
| 1.0
| Weight for grade of this metacriterion.
|-
| name
| varchar(255)
|
| Human-readable name of this metacriterion.
|}

=== Backup/Restore ===
TODO

== See also ==
* [[Advanced grading methods]]
* [[Advanced grading API]]

Meta AGM

2014-11-30T22:26:28Z

Nixo:

== General information ==
'''Project goal:''' to be able to use multiple [[Advanced grading methods]] at one grading area.

'''Project scope.''' This project does not change the AGM internals and its API. Meta AGM is a grading method, the form of which is a number of another AGMs.

== Use cases ==
In examples below 'rubric' and 'criterial' grading methods were used. Criterial is a work-in-progress method which allows teacher to define a form with a number of numerical fields, checkboxes, etc.

=== 1. Assessment of student's program on the course of high-level programming basics ===
There are lot of aspects of checking the quality of program which is developed by student: efficiency, code style compliance, lab activity protocol... So we need a various grading method types to develop a set of criterions allowing us to assess all the aspects described in one assignment module.

TODO: defined AGM example

== Implementation ==
This module allows a teacher to define several metacriterions and define different grading methods in it. The teacher defines metacriterions by himself.

While AGM design allows us to have only one active grading method in one gradeable area, we can create more areas (fake areas actually) for the same context. We call it 'metacriterions'. It's safe because any other modules uses MODULENAME_grading_areas_list() to list the areas, not DB query.

=== How it works ===
[[image:metaagm-sd.png|400px|thumb|left|UML sequence diagram of how the teacher defines the metacriterions and what happens in DB during this process.]]

1.1 ''Get the metacriterions list:'' list of areas for current contextid and module will be returned (except the area which Meta AGM is defined in).
3.2.1.1: A new record with fake area for current contextid and module will be inserted to grading_areas table and a record to gradeform_metaagm_areas (see below).

=== DB schema ===
[[File:metaagm-erd.png]]

==== gradeform_metaagm_areas ====
Each metacriterion additionally listed in this table. There are weight and name fields are important. Teacher can define a human-readable name for each metacriterion and a weight of grade for this metacriterion.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered
|-
| '''areaid'''
| bigint
|
| The gradeable area for metacriterion.
|-
| weight
| float
| 1.0
| Weight for grade of this metacriterion.
|-
| name
| varchar(255)
|
| Human-readable name of this metacriterion.
|}

=== Backup/Restore ===
TODO

== See also ==
* [[Advanced grading methods]]
* [[Advanced grading API]]

File:metaagm-sd.png

2014-11-30T22:16:01Z

Nixo:

Meta AGM

2014-11-30T20:45:54Z

Nixo:

== General information ==
'''Project goal:''' to be able to use multiple [[Advanced grading methods]] at one grading area.

'''Project scope.''' This project does not change the AGM internals and its API. Meta AGM is a grading method, the form of which is a number of another AGMs.

== Use cases ==
In examples below 'rubric' and 'criterial' grading methods were used. Criterial is a work-in-progress method which allows teacher to define a form with a number of numerical fields, checkboxes, etc.

=== 1. Assessment of student's program on the course of high-level programming basics ===
There are lot of aspects of checking the quality of program which is developed by student: efficiency, code style compliance, lab activity protocol... So we need a various grading method types to develop a set of criterions allowing us to assess all the aspects described in one assignment module.

TODO: defined AGM example

== Implementation ==
This module allows a teacher to define several subareas and define different grading methods in it. The teacher defines subareas by himself.

While AGM design allows us to have only one active grading method, we can create more areas (fake areas actually) for the same context. We call it 'subareas'. It's safe because any other modules uses MODULENAME_grading_areas_list() to list the areas, not DB query.

=== How it works ===
TODO: sequence diagram

=== DB schema ===
[[File:metaagm-erd.png]]

==== gradeform_metaagm_areas ====
Each subarea additionally listed in this table. There are weight and name fields are important. Teacher can define a human-readable name for each subarea and a weight of grade for this subarea.
{| class="nicetable"
|-
! Field
! Type
! Default
! Description
|-
| '''id'''
| bigint
|
| Auto-numbered
|-
| '''areaid'''
| bigint
|
| The gradeable subarea.
|-
| weight
| float
| 1.0
| Weight for grade in this subarea.
|-
| name
| varchar(255)
|
| Human-readable name of this subarea.
|}

=== Backup/Restore ===
TODO

== See also ==
* [[Advanced grading methods]]
* [[Advanced grading API]]

Meta AGM

2014-11-27T09:55:09Z

Nixo: Added DB scheme

File:metaagm-erd.png

2014-11-27T09:36:03Z

Nixo:

Meta AGM

2014-11-22T21:53:16Z

Nixo: Created page with "== General information == '''Project goal:''' to be able to use multiple Advanced grading methods at one grading area. '''Project scope.''' This project does not change t..."

VSTU projects

2014-11-20T20:17:35Z

Nixo:

==Lead: Sychev Oleg Aleksandrovich==
Senior Lecturer of POAS (Software Engineering) department

===Core patches===
# [[Categories editing interface improvment|Improvment of editing interface for category list]]. Moving category anywhere should require only one page reload. Developers: Sychev Oleg, Shkarupa Alex. Status: waiting reviewing!
# [[Javascript-interface for repeat_elements function|Javascript-interface for repeat_elements function]] - adding new blanks to the form shoudn't require page reloads.
# [[Forum thread subscription|Forum thread subscription]] - a long standing request to be able to subscript only to the thread, not whole forum.
# [[AJAX mod editing|Editing course modules without reloading ]] - adding/editing activities(resources) in AJAX mode without page reloads.
# [[Exporting/importing several question categories at once|Exporting/importing several question categories at once]] - changing the interface of exporting question categories.
# [[Capturing and sending to the server selection user piece of text on the web page|Capturing and sending to the server selection user piece of text on the web page]] - TODO.
# [[Save category description in Moodle XML import/export|Save category description in Moodle XML import/export]] - TODO.

===Activity modules===
# [[Assignment development|New assignment-replacement module]] with support for individual tasks (with custom fields), several grading criterions, automatic graders etc.
# [[Subcourse module improvments|Subcourse module improvments]] - improve Subcourse module to get rid of buggy Metacourses and make it actually useful.
# [[Question-lesson link|A proposition how to link question engine with lesson module]] - adding only two simple functions to the question definition we could create ideal connection with the lesson module, and not only it.

===Question types===
# [https://docs.moodle.org/en/Preg_question_type Preg question type] - regular expression question type, developed on more solid algorithmic basis than regex one.
# [[Auto-feedback shortanswer question|Auto-feedback shortanswer question "CorrectWriting" project]] and [https://docs.moodle.org/en/question/type/correctwriting user documentation] for shortanswer question which could be able to detect typos and misplaced, missing or extra words and give appropriate feedback.

===Question behaviours===
# [https://docs.moodle.org/dev/Hinting_question_behaviours(VSTU) Hinting behaviours] - behaviours that would help standartise hinting from each qtype.

===Blocks===
# [[Linked activities|Linked activities]] to allow editing properties of multiple activities at once.
# [https://docs.moodle.org/en/Formal_Languages_Block Formal languages block] which allows to scan (tokenize) and (future) parse text in several languages (currently english, C, C++).
# [https://docs.moodle.org/en/Auto_role_assignment_block Auto role assignment block] is useful to temporary restrict (or enhance) user abilities while doing something.
# [https://docs.moodle.org/en/Supervised_block Supervised block] is much better than IP filter+time control if you want students to be able to do something only under teacher supervision. Supports out of the box restricting quizzes for supervized sessions only, but very powerful when combined with previous one (auto role assignment), allowing any permission changes.

===Libraries===
# [[Auto-backup library|Auto-backup library]] - adding very small information to install.xml files it is possible to automate many tedious tasks of programming backup/restore for the plugins.

===Grading Methods===
# [[Meta AGM]] - grading method which allows usage of multiple AGM's with one activity at once.

VSTU projects

2014-10-20T17:08:13Z

Nixo:

==Lead: Sychev Oleg Aleksandrovich==
Senior Lecturer of POAS (Software Engineering) department

===Core patches===
# [[Categories editing interface improvment|Improvment of editing interface for category list]]. Moving category anywhere should require only one page reload. Developers: Sychev Oleg, Shkarupa Alex. Status: waiting reviewing!
# [[Javascript-interface for repeat_elements function|Javascript-interface for repeat_elements function]] - adding new blanks to the form shoudn't require page reloads.
# [[Forum thread subscription|Forum thread subscription]] - a long standing request to be able to subscript only to the thread, not whole forum.
# [[AJAX mod editing|Editing course modules without reloading ]] - adding/editing activities(resources) in AJAX mode without page reloads.
# [[Exporting/importing several question categories at once|Exporting/importing several question categories at once]] - changing the interface of exporting question categories.
# [[Capturing and sending to the server selection user piece of text on the web page|Capturing and sending to the server selection user piece of text on the web page]] - TODO.
# [[Save category description in Moodle XML import/export|Save category description in Moodle XML import/export]] - TODO.
# [[System-wide submission methods]] - a submission methods which are usable with any plugin.

===Activity modules===
# [[Assignment development|New assignment-replacement module]] with support for individual tasks (with custom fields), several grading criterions, automatic graders etc.
# [[Subcourse module improvments|Subcourse module improvments]] - improve Subcourse module to get rid of buggy Metacourses and make it actually useful.
# [[Question-lesson link|A proposition how to link question engine with lesson module]] - adding only two simple functions to the question definition we could create ideal connection with the lesson module, and not only it.

===Question types===
# [https://docs.moodle.org/en/Preg_question_type Preg question type] - regular expression question type, developed on more solid algorithmic basis than regex one.
# [[Auto-feedback shortanswer question|Auto-feedback shortanswer question "CorrectWriting" project]] and [https://docs.moodle.org/en/question/type/correctwriting user documentation] for shortanswer question which could be able to detect typos and misplaced, missing or extra words and give appropriate feedback.

===Question behaviours===
# [https://docs.moodle.org/dev/Hinting_question_behaviours(VSTU) Hinting behaviours] - behaviours that would help standartise hinting from each qtype.

===Blocks===
# [[Linked activities|Linked activities]] to allow editing properties of multiple activities at once.
# [https://docs.moodle.org/en/Formal_Languages_Block Formal languages block] which allows to scan (tokenize) and (future) parse text in several languages (currently english, C, C++).
# [https://docs.moodle.org/en/Auto_role_assignment_block Auto role assignment block] is useful to temporary restrict (or enhance) user abilities while doing something.
# [https://docs.moodle.org/en/Supervised_block Supervised block] is much better than IP filter+time control if you want students to be able to do something only under teacher supervision. Supports out of the box restricting quizzes for supervized sessions only, but very powerful when combined with previous one (auto role assignment), allowing any permission changes.

===Libraries===
# [[Auto-backup library|Auto-backup library]] - adding very small information to install.xml files it is possible to automate many tedious tasks of programming backup/restore for the plugins.

POAS Assignment development

2014-10-20T16:46:25Z

Nixo:

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Assignment 1.9 Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins

== POAS Assignment Refactoring ==
We are planning to reorganize our code base. The main purposes are:
* make it more flexible,
* distribute a responsibility correctly.

Along the way, calls of deprecated functions and methods will be removed (e. g. Logging).

Key points are:
* ''Namespaces.'' All classes will be organized using namespaces (like java packages).
* ''Automatic class loading.'' Reduce usage of require().
* ''Usage of modern API.'' Events 2, Logging 2, etc.
* ''Advanced Grading Methods.'' The criterions will be replaced with a separate AGM plugin (POAS Criterial Grading Method or Accumulative Grading Method<sup>[Issue link?]</sup>). The POAS Assignment will support AGM.
* ''Usage of Assignment 2 submission methods''.
* ''A minor visual changes.''

Known issues:
* The Assignment 2 submission methods does not allow their usage with other plugins (MDL-47344).

Planned namespace structure for mod_poasassignment is:
* '''classes/'''
** '''model/'''
*** assignment
*** individual_task
*** ...
*** '''submission/'''
**** base
*** '''distribution+strategy/'''
**** base
*** '''grader/'''
**** base
** '''view/'''
*** '''form/'''
*** '''page/'''
**** base
** '''event/'''
*** instance_available
*** assessable_submitted
*** ...

== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| '''\mod_poasassignment\event\instance_available'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| '''\mod_poasassignment\event\instance_unavailable'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| '''\mod_poasassignment\event\task_selected'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| '''\mod_poasassignment\event\assessable_submitted'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| '''\mod_poasassignment\event\submission_graded'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Teacher's user ID.
; relateduserid : Student's user ID.
; other->isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]

POAS Assignment development

2014-10-02T14:19:16Z

Nixo:

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Assignment 1.9 Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins

== POAS Assignment Refactoring ==
We are planning to reorganize our code base. The main purposes are:
* make it more flexible,
* distribute a responsibility correctly.

Along the way, calls of deprecated functions and methods will be removed (e. g. Logging).

Key points are:
* ''Namespaces.'' All classes will be organized using namespaces (like java packages).
* ''Automatic class loading.'' Reduce usage of require().
* ''Usage of modern API.'' Events 2, Logging 2, etc.
* ''Advanced Grading Methods.'' The criterions will turn into a separate AGM plugin. The POAS Assignment will support AGM.
* ''Usage of Assignment 2 submission methods''.
* ''A minor visual changes.''

Known issues:
* The Assignment 2 submission methods does not allow their usage with other plugins (MDL-47344).

== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| '''\mod_poasassignment\event\instance_available'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| '''\mod_poasassignment\event\instance_unavailable'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| '''\mod_poasassignment\event\task_selected'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| '''\mod_poasassignment\event\assessable_submitted'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| '''\mod_poasassignment\event\submission_graded'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Teacher's user ID.
; relateduserid : Student's user ID.
; other->isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]

POAS Assignment development

2014-03-16T10:44:48Z

Nixo: /* Events */ A small clarification about 'isfinal'

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins
== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| '''\mod_poasassignment\event\instance_available'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| '''\mod_poasassignment\event\instance_unavailable'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| '''\mod_poasassignment\event\task_selected'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| '''\mod_poasassignment\event\assessable_submitted'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| '''\mod_poasassignment\event\submission_graded'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Teacher's user ID.
; relateduserid : Student's user ID.
; other->isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]

POAS Assignment development

2014-03-16T10:39:19Z

Nixo: /* Events */ Event data changed according to Event 2 API.

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins
== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| '''\mod_poasassignment\event\instance_available'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| '''\mod_poasassignment\event\instance_unavailable'''
|
; contextinstanceid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| '''\mod_poasassignment\event\task_selected'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| '''\mod_poasassignment\event\assessable_submitted'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| '''\mod_poasassignment\event\submission_graded'''
|
; contextinstanceid : Poasassignment course module ID.
; userid : Teacher's user ID.
; relateduserid : Student's user ID.
; isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]

POAS Assignment development

2014-03-14T19:03:46Z

Nixo:

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins
== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| '''\mod_poasassignment\event\instance_available'''
|
; cmid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| '''\mod_poasassignment\event\instance_unavailable'''
|
; cmid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| '''\mod_poasassignment\event\task_selected'''
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| '''\mod_poasassignment\event\assessable_submitted'''
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| '''\mod_poasassignment\event\submission_graded'''
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
; isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]

POAS Assignment development

2014-02-27T17:32:13Z

Nixo:

{{Moodle 2.0}}
This was a proposition of Assignment module development from POAS department of Volgograd State Technical University.
We don't want to fork from core, but was forced to do it by Moodle team. So it will be a separate module, that you can use instead of standard assignment. There may be a convertor some time ago.

New module name will be a poasassignment.
== Assignment 1.9 improvements ==
Just several simple, but useful improvements that can be done in stable version too:
# Usability improvement: on submission.php add a combo box to filter the content of the table: Show all/with submissions/await grading. That speed up grading much. See MDL-14238
# New capability: viewownsubmission. Setting it to Deny makes assignment module useful in exam context - collect student's work without their further access to it. See MDL-15356
# Replace link with the number of submissions (for the teacher) with more informative "The ___ of ___ submissions needs grading". MDL-17613

== Refactoring ==
Some areas of assignment can be reworked for greater flexibility and reducing code duplication. Assignment base is actualy an awful, bloated class where all things are intermixed. And any plugin inherits it fully. Some plugins have similar features too, implemented separately. Overall issue for this is MDL-17329.

Some major improvments:
* 'types' will be no longer considered separate activities, just a option in the mod_form
* 'type' plugins, which defines what can be submitted, will be reduced to just that purpose, all workflow would be controlled from main module (reducing numerous duplicates and inconsistences)
* there will be two basic 'type' plugins (text and files), which can be used in any combination (from no one to both)
** no one is effectively an offline task
** files (reworked upload) can serve for both single and multiple files uploads
* there will be possible to create new activities based on this module, inheriting it's main classes, for major workflow customisations, and they will have full access to 'type' plugins
== New Features ==

=== Teams ===
This feature is on hold and may wait for a second version of module. Right now we are more focused on task distribution

One main assumption in the assignment module is need to be eliminated is "one user=one submission=one grade". The quite common practice is grouped assignments, where students can work in small groups on a task. So we need a teams support there. (Well, quite big work as many functions use this assumption).

'''Team''' is a group of students whose work will results in one submission. Teams features:
* submission is one per team, but a grade can be given on per-team or per-student basis
* teacher can define a minimum and maximum number of students in the team
* self-organization (with possibility of confirmation by teacher) or forced by teacher teams
* maximum date of team membership editing
* teacher can add themselves to teamas a mentor, then he only will be notified of events in this team
* 'roles' (or workroles to avoid confusion with Moodle Roles) of people in team (either teacher or student defined) - this is a way to explain who in group will do what
** teacher-defined roles is a list, from which one or several roles can be selected for students
** if teacher doesn't want do define specific roles, students can enter text, explaining their role in the group

=== Individual tasks ===
Individual tasks is quite common situation in the educational process. The module can handle tasks selection and completion.

Individual tasks features:
* adding/editing/deleting of tasks by the teacher
* standart fields: name, description, grade factor (1 by default), min/max teamnumber (if teams activated)
* custom fields, which can be added in any given assignment, of several types: string, text, number, date, menu, file
* some fields can only be accessible to the student once he is selected a task (and it will be approved by a teacher if necessary)
* student's selection (with optional teacher approval), teacher-forced selection or random selection based on a student's selection of subset of tasks fields (number or menu mainly, i.e. some sort of 'complexity' field for example)
* maximum dates of selection (and approval if necessary)
* column with task name (link to the task) when grading
* random filling of some task fields (number or menu mainly) on selection or approval
** there is some problem of misuse of random generator; they are mainly dealt with fact that student's can change task and select new without teacher

=== User interface - tabs ===
Currently assignment have only two main pages: intro/submit (view.php) and grading (submission.php), so it can go away with the link in upper right corner.

New features will require more pages, so it's better to use tabs for them. Tabs visibility will be based on user's capabilities.

Urgent reminders will be places on top (or bottom?) of every tab with color highlighting;
* for students
** if he is late to select a task/become a member of team
** if he is late to submit work
* for teachers
** if student from his/her group asks to delete him from team (or task change)
** if there are students without task/team after date of last approval

=== Grades aggregation ===
Sometimes teacher want to grade student's submissions by several grading scales and than having the computer to calculate resulting grade. Is this possible using gradebook or should be duplicated in module is under investignation.

=== Grading semi-plugins ===
Sometimes assignments allow for automatic, or semi-automatic grading. It's nice to have options to have a plugin system for this.

=== ''maybe'' One user can get several tasks ===
That needs further discussion. It's something not very uncommon in real word teaching, but somewhat difficult to cope with "one course module=one grade" thing.

=== Tasks workflow ===
Let's see a task workflow in most complicated case (maximum features will be used). States names are somewhat awkward and is subject to change (can anyone propose better names?)

* initially task is '''free''' (1)
* (1) student or teacher can create a team -> '''creating team''' (2)
* (2) student(s) can add themselves to the team, teacher can add students to the team (in last case student notified that he/she was added)
* (2) students can plead to free them from team/task, teacher can disapprove (if allowed) members or task (students is notified if they are disapproved)
* (2) after the team will have at least minimum number of participants -> '''have enough people''' (3)
* (3) all (2) operations still available
* (3) students can confirm his will to work with team(now that he knows all it's members), teacher can approve a team - approvment automatically cleared if team membership changes (people that have approves is notified)
* (3) after the date of last approval, no more changes in teams available for students, (for teachers it's depends on capabilities), if there is an unapproved team the teacher will be shown (and sent) urgent reminder
* (3) after the students (if allowed) approved a team and task -> '''ready''' (4) (if teacher approvment needed) or '''working''' (5) (students and teacher notified)
* (4) after teacher approval -> '''working''' (5) (students notified)
* (4) in case of teacher disapproval -> '''have enough people''' (3) (students notified)
* (5) any student in the team can submit work with flag 'please check our progress' (if allowed), then teacher is notified and able to give comment but not grade (teacher notified, student's notified of comment)
* (5) any student in team can make a normal submit, but it (optionally) may need an approval from other members for grading -> '''await grading''' (6) (teacher notified)
* (6) the teacher can only grade a team in '''await grading''' status
* (6) teacher grades, but grade isn't final -> '''reworking''' (5) (students notified)
* (6) teacher gives final grade -> '''graded''' (7) (students notified)
* (7) person of higher authority will be able to override grade and add something to comment (but maybe not freely edit it, the name of the first grader and regrader will be saved in comment). (students and teacher notified)

Well it's probably looked worse than is. The actual user will see only part of options, and all forms of approval can be disabled.

=== Files handling ===
There is some confusion about files handling in current version of assignment module. This is need to be corrected. So there should be a several types of files:

# '''assignment''' files - files that is showed and accessible to all, and associated with assignment in general even if individual tasks is used (such as guidelines for it's completion that apply to all regardless of individual task);
# '''task''' files - some file(s) that teacher want to give students before they start to work on particular task;
# '''submission''' files - files that was submitted by a particular student (team);
# '''reply''' (comment) files - files that was uploaded by a teacher when grading submitted work, usually rewised versions of submitted files (thanks to A.T. Wyatt comment there)

== Implementation ==

=== New options ===
Let's see an assignment creation/editing screen. Assignment module will keep all existing options.

New options that will be added:
* use individual tasks
* use teams
* last date of approval - active if tasks or teams used, time to which all considerations about group memebrship and tasks selections must be done
* team options (active only if teams selected)
** min and max count of members of team
** the grade will be individual or one per team
** if students must confirm it will to work with team (first student, who create a team, may not be happy with someone who add yourself to it later)
** if teacher must confirm team membership
** if all team members must confirm a submission before grading
* individual task options (active only if tasks is selected)
** allow using same tasks - can several students do one task or all tasks must be different?
** allow using same tasks in one group
** individual date - allow individual due dates to the task
** individual team members count - if teams used, can particular task override min/max number of students in team
** teacher must confirm task selection
** random task assignment

=== DB structure ===
[[Image:db schema.jpg]]

The new db structure have such tables:
* '''poasassignment''' - main table which have new options :
*# maxmembersontask - maximum count of members which must to do the task
*# minmembersontask - minimum count of members which must to do the task
*# mintaskonmember - minimum count of tasks for one member(needs discussion)
*# maxtaskonmember - maximum count of tasks for one member(needs discussion)
*# timedistrib - initial time for task distribution
*# timeconfirmation - the date after that a student not may create/come into new working group
*# timereception - start time for tasks reception
*# flags - all binary options
* '''poasassignment_tasks''' - table for task list of instance of activity:
*# name - the name of task
*# descripiton - task "body"
*# deadline - individual date for task reception
*# factor - factor for grade
*# maxmembers - maximum workgroup members on task
*# minmembers - minimum workgroup members on task
* '''poasassignment_fields''' - define list of custom fields:
*# ftype - type of the field
*# name - name of the field
*# showintable - additional column in table of tasks
*# maxvalue - maximum value for the field(only numbers)
*# minvalue - minimum value for the field(only numbers)
*# optional - optional field?
*# rndparam - if this field used to define filter for random selection of task
*# rndshow - if this field will get random value on task selection (number or menu fields only)
* '''poasassignment_field_consts''' - define consts for the fields type of list
* '''poasassignment_values''' - values for particular task/workgroup
* '''poasassignment_workgroups''' - table for teams, also submissions stuff go there
* '''poasassignment_workgroup_members''' - members of teams, grade stuff go there:
*# userid -
*# grade - this is the grade for submission
*# submissioncomment -
*# format,teacher,timemarked,mailed - old fields of assignment_submissions
*# ownrole - role which student want implement during task execution
*# finalgrade - final grade(yes/no)?
*# deletefrom - please kick me from this working group (or task)
*# deletecomment - explanation why student needs to delete from this working group
* '''poasassignment_role''' - roles for the task:
*# one task have many roles
*# one student perform many roles
Rethink tables/columns, define how a type plugin can use db, rename workgroups into teams everywhere --[[User:Oleg Sychev|Oleg Sychev]] 11:12, 11 September 2009 (UTC)

=== Tabs ===

==== Info/submit ====
This is an initial tab, that will work basically the same as before.

New abilities:
* show additional dates (i.e. dates of last approval and so on)
* student: show individual task (?tasks?) when the individual tasks is selected
* student: show task status (see workflow of the task above)
* student: show team members (when teams used)
* student: can approve team and submission, select or type his roles
* teacher: the number of submissions will be shown JFI as there is a tab for grading now (maybe as a link, just as in quiz now - it must be moved to down center area)
* teacher: the number of submissions will be showed as <need grading>/<all submissions>

==== Custom fields ====
This tab is for managing custom fields for the tasks. The author can add/edit/delete fields there.

==== Tasks ====
New tab, accessible when individual task feature activated.

Abilities:
* teacher: adding, editing, deleting a task (editing and deleting assigned tasks may be prohibited)
* student: browsing task list, viewing task details
* student (without teams): selecting a task
* student (in team mode): see current teams(at least incomplete), create team for a task, apply for team membership

==== Grading ====
This is an evolved grading page (submission.php), for teachers use.

New abilities:
* the table will reflect a status of task (maybe with icons)
* individual tasks: the table will additionally reflect task name (as a link to popup with it's description) and a grade factor
* teams: the table (and popup for grading too) will have two modes:
* teams and/or individual tasks: in case any form of teacher approvment is needed, columns for approvment will be showed
* grade columns/popus will be showed only when grading is allowed (or if person has mod/assignment:manageanything capability)
*# team grades - each string represent a team
*# individual grades - each string represents a student, but they are sorted by team and teams is spaced somehow
* make an option for the teachers to make any grade final, forbidding further re-submissions and/or regrading (a person with mod/assignment:manageanything can still regrade); in teams with individual grading mode re-submission will be forbidden only when all team members receive final grade
* dropdown to choose whom to display in the table (and in the popup): all, with submissions only, needs grading only

=== Capabilities ===
Current capabilities
* mod/poasassignment:view - actually quite strange capability that can completely block you from assignment
* mod/poasassignment:submit - ability to submit a work
* mod/poasassignment:grade - ability to grade submissions

New capabilities
* mod/poasassignment:viewownsubmission (can be backported to 1.9) - sometimes we need to not allowing the student to see own submission (exams cases mostly)
* mod/poasassignment:manageanything - person with high authority, for whom don't apply usual restrictions: he can edit/delete tasks on which people worked right now, manage group membership and their tasks after an approval, override final grades and so on
* mod/poasassignment:managetasks - ability to create, edit and delete tasks
* mod/poasassignment:managefields - ability to manage custom fields of tasks
* mod/poasassignment:finalgrades - can make grades final
* mod/poasassignment:manageteams - ability to create, force students to the team, approve students (teacher's ability)
* mod/poasassignment:managetaskselection - ability to manage tasks selection for any student (teacher's ability)
* mod/poasassignment:manageownteam - ability to create new team, apply to existing one, confirm memebership of the others in this team (student's ability, setting it to Deny will create an task where only teachers can manage teams membership)
* mod/poasassignment:selectowntask - student's ability to select task (setting to Deny allows for teachers-only tasks selection)
* mod/poasassignment:seeotherstasks - student's ability - if he/she is able to see what tasks are selected by other people, or he can see only if it free for selection

=== Events ===
Events will be added in future releases.
{| class="nicetable"
|-

! Event name
! Event data
! Description

|-

| poasassignment_instance_available
|
; cmid : Poasassignment course module ID.
| Fired when 'available from' time comes (if specified), instantly when creating a course element or when element become visible to the students.

|-

| poasassignment_instance_unavailable
|
; cmid : Poasassignment course module ID.
| Fired when time for submissions expired, course module hidden from students or deleted.

|-

| poasassignment_task_selected
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when an invidual task is selected for the student (either by himself, by teacher or automatically)

|-

| poasassignment_answer_submitted
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
| Fired when the student adds a ''non-draft'' submission.

|-

| poasassignment_submission_graded
|
; cmid : Poasassignment course module ID.
; userid : Student's user ID.
; isfinal : Is this grade final.
| Fired when the student's attempt is graded by the instructor.
|}

[[Category:Assignment]]