Non-standard means php.ini was set to something not in the default list (like 7MB),
then the config was saved to that specific value, and now the value in php.ini has been changed
again so 7MB does not appear in the list.
Example submissions settings moved into a dedicated section.
Self-assessment setting moved to the assessment section. There is no
need for the dedicated Workshop features section any more. All Workshop
feedback settings moved into a dedicated section.
Reorganised grading settings - the grading strategy put into the top
place as it is the essential setting. All other three settings are
related to calculating actual grades.
No advanced setting fields in the Workshop form. Mixing collapsible
sections with advanced fields (that are not even marked as "advanced"
any more) does not work well.
AMOS BEGIN
CPY [feedback,mod_assign],[feedbacksettings,mod_workshop]
AMOS END
There was a plan to make use of it initially when Workshop was rewritten
for Moodle 2.0. The idea was that the Workshop could be switched into a
simplified mode where teachers only make assessments (with all the
grading strategies available). But things evolved since then and now we
have Advanced grading methods available in the new Assignment module
that solves the use case well. So, having this option available is not
only confusing but - looking at the code - pretty useless.
For now, I am just hiding the setting from the settings form and the
code always considers it as if it was enabled. In the future, the field
can disappear from the database, too.
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
Three new fields are added into the into the Assessment settings section
of the form. The default value for the overallfeedbackmaxbytes is the
same as the maximum size for submission attachments (which seems to be a
reasonable value). If there is a demand and a strong use case, these
values can became per-site configurable (I can see no big benefit of
doing so right now).
AMOS BEGIN
CPY [maxbytes,mod_workshop],[overallfeedbackmaxbytes,mod_workshop]
AMOS END
These three fields hold the per-instance settings for the new Overall
feedback feature. Expected values in the new overallfeedbackmode fields are:
0 - the feature is disabled in this workshop instance
1 - overall feedback is optional (default)
2 - overall feedback is required (i.e. the reviewer must put some text
into the overall feedback field).
Files can be attached to the overall feedback text field, if the field
overallfeedbackfiles > 0 and the feature is enabled (i.e. it is optional
or required). The actual number of attached files is not checked in the
required mode (i.e. attaching files is always optional, if it is
allowed).
The $sql used in these methods may contain multiple parts glued
together by the UNION operator. Simply appending the ORDER BY statement
to the end of the query does not work in all DBs (failure reported at
Oracle). Following the pattern already applied in MDL-30051, we wrap the
SQL into yet another SELECT statement and perform ordering there.
Credit goes to Sara Cenni for suggesting the fix.
If the user is allowed to see the published submission, she must be also
able to see images in it (both embedded into the text as well as
attached to the submission). See the logic in submission.php as a
reference.
This change removes the "0 bytes" option from the get_max_upload_sizes list
and replaces it with "Course limit (X)" or "Site limit (X)" (whichever is smaller).
This means we can remove all custom handling in the modules that were removing and
adding these options. It only affects pages that pass valid options for sitelimit and
courselimit - so admin pages will work correctly.
It also orders the list so the course/site limit options will be first
(as it will be the largest).
AMOS START
REM [courseuploadlimit, core] has been parameterized to get [uploadlimitwithsize, core]
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
This is a simple wrapper around workshop::get_assessments_by_reviewer()
that filters assigned assessments and returns just those that were not
graded by the reviewer yet.
Now we are checking for the need to execute the allocator every time the
main view.php is displayed to any user. Previously this was done by cron
only.
Now we are checking for the need to switch the phase when the main
view.php is displayed to any user (previously this was done via cron
only). To give our subplugins (such as the scheduled allocation method)
a chance to do what they need to do, the workshop_viewed event is
triggered before the phase is actually switched.