There was a bug with serving the files from the areas instructauthors,
instructreviewers and conclusion. These three areas should not use the
itemid in the plugininfo URLs. But they did use 0 as the itemid which
broke the file previews when browsing via server files repository.
The first part of the patch fixes all relevant calls to
file_rewrite_pluginfile_urls() so that null is now properly used instead
of zero.
The second part of the fix is that we no longer delete the first $args
element in the workshop_pluginfile() function - the itemid is not
supposed to appear there now.
The last part of the patch is that instead of repeating the same code
block copy&pasted for each file area in workshop_pluginfile(), we now
have a single block covering them all.
When editing existing workshop with a grade to pass defined, when the
field is emptied, it should be interpreted as setting it to zero. This
was not happening because unformat_float replaces the field with null,
therefore effectively unsetting it.
By casting to float, we interpret all empty values (including null) as
zeros. This behaviour is consistent with how gradebook setup UI works.
This is basically a clean up and what I think improved version of the
original Mahmoud's patch.
The actual checking for allowed file extensions has been re-implemented
and is now covered by unit tests. The list of allowed extensions is now
also assed to the filemanager element's accepted_types option to prevent
picking other files (we still need the in-place validation though). The
form validation is simplified a bit. The custom validation of file size
introduced in the previous patch has been removed as not related to this
issue (also I believe it should not be done at this level).
This is built upon original work by Michael Hughes. We now have separate
settings for deleting workshop submissions, assessments and for resetting the
workshop phase.
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.
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.
The documentation suggested that the modname field should be present on the
$workshop parameter when this is not required. It is not used in any point
in the function and the $workshop variable is never passed to another
function which may use it.
Teachers can now choose the actual grading evaluation method to use
during the grading evaluation phase. The workshopeval_best is still used
as the default one (this may be made configurable later, although there
is no big benefit of it).
The workshop_pluginfile() can't be more restrictive than the code that
actually displays the text with the embedded images. To view both
instructions fields in view.php, the capability to view the workshop is
enough. So the same level of access control is applied here by
require_login() at the top of the function.
The user has to have viewallsubmissions capability to be able to see the
submission files in the browser. Additionally, in the separate groups
mode, the user has to have accessallgroups or share at least one group
with the submission author to view their files.
As discussed in MDL-32631, calendar_event::update() should not do
capability checks at all. Until that issue is fixed, we just explicitly
declare that no capability checks should be done.
The function workshop_calendar_update() is executed when adding or
updating a workshop instance (where permissions to modify the instance
were already checked and are sufficient) and in the upgrade code (where
no check should be performed anyway).
David Mudrák