version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
The availability restrictions that apply to user lists (group, grouping)
now apply in workshop:
* In user lists.
* When randomly allocating users (also now works as expected if you use
group mode and a grouping with the activity).
In order to use the overall feedback in assessments of example
submissions and in the assessment form preview, significant improvements
in the rendering machinery were done.
Workshop class provides two new methods overall_feedback_content_options()
and overall_feedback_attachment_options() as they are needed at various
scripts and libraries.
Overall feedback is displayed as a part of the workshop_assessment_form
only if the form is in editable mode (not frozen). If the form is
displayed in read-only (frozen) mode, the caller is expected to render
the overall feedback and list of attachments (the editor and filemanager
elements do not support frozen mode). To do so, the renderable
workshop_assessment now loads overall feedback data and provides two new
methods get_overall_feedback_content() and
get_overall_feedback_attachments() to be used by the renderer.
Renderable workshop_submission, workshop_assessment and related classes
now accept the workshop instance as the first parameter in their
constructors. This way, these renderable classes have access to the
workshop API.
In the future, the rendering of submission files should be improved in
the same way as is done in this patch (i.e. moving the logic and data
preparation out of the renderer into the renderable classes).
The assessment form can be displayed as editable or read-only (frozen).
Neither the editor element nor the filemanager element support
displaying frozen content themselves so we need to pre-format and inject
static texts.
The list of attachments should be ideally generated by the renderer and
probably improved a bit - just quick and dirty solution must be enough
for now though (2.5 coding freeze is just behind the corner...).
AMOS BEGIN
CPY [submissionattachment,mod_workshop],[feedbackauthorattachment,mod_workshop]
AMOS END
The button is displayed only when there is a pending (that is not
assessed yet) submission to assess.
AMOS BEGIN
CPY [savenext,mod_assign],[saveandshownext,mod_workshop]
AMOS END
Obvious problems emerged once there were some records in the
workshopform_rubric table with no workshopform_rubric_levels. As l.id
(empty in that case) was used as the key of the returned array, they all
were collapsed into a single one.
QuickForms do not distinguish non-checked radio from the checked radio
with the value "0". So we map the database grade value "0" to a value
"-1" when displaying the form and vice versa when saving the form. This
allowed us to have none radios checked by default and force the grader
to actually answer the form themselves, using the 'required' rule.
This patch introduces a new hidden field with the value "-1". The grade
selectors are compared with this values and must be greater than it.
This should fit well for numerical grades with the range 0..x and scale
items with the range 1..x.
New PARAM_COMPONENT, PARAM_AREA and PARAM_PLUGIN + fixing of hopefully all current incorrect parameter types. This should help with diagnosing of incorrectly named 3rd party plugins too.
The Workshop module using the "Number of errors" grading strategy did
not save all items in the grade mapping table. If some assessment form
fields have weight > 1, the number of possible errors is greater that
the number of the assessment form fields. The previous code deleted all
mappings where the number of errors was greater than the number of
fields.
In this patch, the maximum number of possible errors is calculated as a
sum of weights of all fields. Only mappings over this maximum are
deleted now.
