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).
The idea is to build a plugin that will internally call the random
allocator when the submissions deadline is reached. The teacher is able
to pre-define the configuration for the random allocator.
The random allocator's init() method was split into two logical
parts. The init() now handles data from the form and executes the new
execute() method to do the actual job. The execute() method will be
called by the future scheduled allocator, too.
