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).
Note that most line changes in the patch are caused by the recent
changes in the XMLDB TEXT fields handling (no size specified now) and by
the change in the indentation.
On every invocation, the workshop will give its subplugins a chance to
to something useful. For now, we know that the scheduled allocator will
use it, no need to load other plugin types yet (until there will be a
real reason for it).
For modules that still used the 'old' generic object return from _get_coursemodule_info instead of returning a cached_cm_info object, I changed them to use the new format as part of this. This made a few areas of code regarding onclick links slightly nicer.
Because the Workshop module creates two grade items in the gradebook, we
can't use standard modedit features to set the corresponding category in
the gradebook (it supports single grade item only).
The patch also cleans the mod_form.php so that it does not use the
global $COURSE (just because I do not like this global variable).
And for the record - QuickForms must die.
* Added the component and ratingarea fields and implemented it throughout
the rating API as mandatory fields
* Cleanup rating indexes
* Upgrade forum/data/glossary ratings
* Moved the logic in the render_rating method to methods of the rating object.
* Added new callback for checking ratingareas
* Cleaned comments here and there
* Mark the xxx_get_participants methods as deprecated
* Refactor rate_ajax and ratingsuser_can_view_aggregate methods
* Cleaned up rating/index.php to use html_table object and moved inline styles to CSS.
* Added missing properties of the rating object that were being set throughout the rating
API.
Adrian Greeve