Obvious problems emerged once there were some records in the
workshopform_rubric table with no workshopform_rubric_levels. As l.id
(empty in that case) was used as the key of the returned array, they all
were collapsed into a single one.
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.
This is a big win, we are now taking enrolment fully into account.
Also, no need to fetch big data from DB just to get their count. Should
have much better performance now.
Workshop grades reports in all three last phases were fixed to support
the group selection. They layout of the report has been unified to be
consistent across all phases.
Note how the participant is defined: it is a user that (1) can submit or
assess or both and (2) is actively enrolled in the course. This means
that usually admins or managers won't be considered as workshop
participants, for example.
If the method is called with $groupid set to 0 and the workshop is in
the groupmembersonly mode, a recursive call is used to populate the
fragments of SQL code that fetch users from all relevant groups. These
fragments are then concatenated using UNION statement.
This patch reimplements get_potential_authors() and get_potential_reviewers()
so that get_enrolled_sql() is used instead of get_users_by_capability().
This excludes non-enrolled users (or users with suspended enrolment)
from the list of potential users.
The patch also extends the returned user structure. Objects in the
returned collection are now suitable for user_picture renderer.
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).
The signature of mod_workshop_mod_form::validation() is now compatible
with that of moodleform_mod::validation() even though the parent's
declaration sucks. No one can choose their parents.
Due to complex workshop upgrade path from 1.9 and missing calendar events
support in 2.x, the only safe way to get rid of potentially invalid
calendar events (such as those reported in MDL-26687) is to remove all
current workshop events and recreate them from scratch.
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.
Removing the table "scheduled" created by the XMLDB by default (it's a
bug in XMLDB, I'm just too lazy now to fix it). Adding new fields to
hold the result of the most recent execution.
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).
