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.
When the workshop class constructor signature was designed, the class
cm_info did not exist yet. Instead, plain course modules records were
used everywhere - including the $mod parameter in the
workshop_user_complete() callback. Even if cm_info is backwards
compatible with the plain data record when it comes to behaviour, it
must not be passed where the workshop API expects the stdClass (coding
error is thrown).
Alternative solution would be to remove the type hinting in the workshop
constructor. That is what the 'assign' class does, for example (the
inline docs describe the expected type to be stdClass, but that is not
forced via the method declaration).
As the problem seems to be pretty sole, I prefer not touching the
workshop internal API for now. So we let the cm_info degrade back into
the stdClass to make the workshop constructor happy without significant
performance lost.
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).
Marina Glancy