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.
These scenarios should cover common cases of defining the grades to pass
pass via the workshop settings form. Note that behaviour of the fields
in terms of locale-specific decimals input (MDL-51806) is not covered
with these tests as I want to avoid installation of additional language
pack. Instead, I assume that functionality of unformat_float() is tested
separately in the core.
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.
As a regression of MDL-55360, it was not possible to create new
workshops if the field "Submission grade to pass" or "Assessment grade
to pass" was left empty. The validation failed with "You must enter a
number here".
The fields submissiongradepass and gradinggradepass are always present
as we explicitly define them in the mod form. So the isset() condition
in the validation was useless and it did not allow to submit the form
with these fields empty.
Additionally, the unformat_float() returns null only if it receives
empty value on the input. Which can't happen in our case so I am
removing this condition to improve the readability of the code.
While testing the issue MDL-55289 I realized that attaching files to
workshop example submissions does not work at all and throws an error.
The reason was that in MDL-50794 (996f7e82), the variables $contentopts
and $attachmentopts were replaced with the result of the methods
submission_content_options() and submission_attachment_options().
But I forgot to perform the full refactoring in exsubmission.php too.
Attached behat test should cover both issues on this branch.
As a result of MDL-41556 (146893d6), the repository/lib.php was included
in submission.php so that its constant FILE_INTERNAL could be used in
field options. Recent development in MDL-50794 (996f7e8) moved the
options declaration to standalone methods but we forgot to check they
work in exsubmission.php too.
This patch moves the repository/lib.php inclusion to where the
library is actually needed.
Additionally it unifies how options are set for overall feedback content
and overall feedback attachment fields.
In a Workshop activity, comment fields on Assessment forms do not properly link to the corresponding Aspect.
So screen reader users may find it difficult to complete the Assessment forms.
There should be a hidden label text for each comment field.
In a workshop activity, on the view submission page where having attachment(s), there's an accessibility issue.
There're 2 separate links for the icon and text which causes an issue for keyboard and screen reader users.
So the text and icon should be combined in one link.
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).
It was reported at the Open University that there have been some
problems with the formats of files submitted by students. Not all
students completed their outlines as a Word .doc (despite this being the
format of the template provided). Some formats (e.g. .pages) couldn’t be
translated by some of the reviewing students. Therefore, they were
unable to provide a review and the submitting students not receiving any
comments.
This patch allows the teacher to define list of allowed file types that
can be attached to submitted work and/or overall feedback in the
workshop.
Some search areas have been introduced as part of the initial search API
and search engine API implementation.
- Forum posts
- Glossary enties
- All moodle activities
This just deletes all the upgrade steps previous to 2.7.0. Some
small adjustments, like adding missing MOODLE_INTERNAL or tweaking
globals can also be applied when needed.
Next commit will get rid of/deprecate all the upgradelib functions
not used anymore in codebase.
I noticed we do not need to list the names of potentially affected
reviewers. If the user (teacher) has the capability to see other
assessments (which they do in 99%), the list of assessments is displayed
at the confirmation page anyway. If for some reason they do not have the
capability, we should not list the names.
The second fix is that the action buttons (such as Delete or Edit) are
not displayed on the removal confirmation page.
And finally, as the output->confirm() wraps the message with implicit
<p>, it is not valid to pass HTML with any block elements. So instead of
concatenating the two messages, we simply define a new string for this
situation.
A new capability is introduced to control this, granted to teacher/admin
roles by default: mod/workshop:deletesubmissions. Additionally, students
can delete their own submissions if they are currently able to edit them.
An old CSS rule which doesn't seem to serve any purpose any more was
causing the "drag and drop not supported" message to be displayed (even
when incorrect) in the workshop assessment form when using a list-view
rubric as the grading strategy.
Rajesh Taneja