Use the current filters and sorting on the user grading table in the single
page grading app when it is possible.
This replaces the popover used to configure the filters to one that closely matches the
one from the grading table. It supports standard filters, workflow filters and allocated marker filters.
It will also support group filtering and suspended user filtering but we don't show the controls for those in
the single grading page.
The capabilities changed ('contextlevel' => CONTEXT_COURSE changed to
'contextlevel' => CONTEXT_MODULE) are:
* moodle/site:accessallgroups
* moodle/site:viewfullnames
* moodle/site:trustcontent
* moodle/site:viewuseridentity
This list came from reviewing the _get_extra_capabilities functions in
all core activities. They were all somewhat inconsistent, but I think it
makes sense that these capabilities are consistently overridable in all
activities. E.g. moodle/site:accessallgroups affects conditional
availability even if there is no other user of groups, and
moodle/site:viewuseridentity and moodle/site:viewfullnames affect the
logs report, if nothing else.
As a result of this, several _get_extra_capabilities functions are no
longer needed, and all the rest have been simplified.
This commit reviews all continue uses in core happening within a
loop / switch / case hierarchy. This does not cover:
- Changes to libraries. Will be handled in another issue / commit.
- Uses out from loops, will be reviewed by other commit.
The policy followed has been:
- When possible, take rid of the continue.
- When clearly the intention was to jump to next element in loop
change to continue 2
- When it was not clear, keep old behavior switching to break, no
matter how weird the behavior may be.
- Prevent group override duedate events from being imported when groups are excluded
- Clean up any existing group override duedate events when editing assignment in upgradelib.php
- Updated lib.php unit tests
The mod_assign_core_calendar_is_event_visible and mod_assign_core_calendar_provide_event_action
functions now accept a new parameter ($userid) so they are not always dependet to the logged in user.
The assign update events code depends on the "old" events in the
DB being returned in the same order as they were originally made,
however there was no guarantee that this would be the case.
There were also situations where the priority would not be explicitly
set (e.g., when creating the "original" event).
- Activities can have their custom completion rules added to cm_info
through the get_coursemodule_info callback.
- Descriptions of a modules active completion rules can be fetched using
the component callback mod_xxx_get_completion_active_rule_descriptions
which takes in a cm_info object and returns an array of strings.
Part of MDL-58138 epic
The only reason the exclusion of require_once was not exploding before
is because the call to provider_event_action() was being triggered first
which required the file. We can't rely on this happening all the time.
The doc update describes when the usage of is_event_visible() is appropriate.
Part of MDL-55611 epic.
We need a way to decide whether an action can currently be completed
(e.g., an assignment where submissions are not yet open can not
be actioned, even though it may be displayed on the upcomming events
list).
To do this, the action interface now contains an is_actionable method.
Part of MDL-55611 epic.
Course modules can now implement the function mod_{module}_core_calendar_provide_event_action
which allows them to return an action to attach to an event.
Part of MDL-55611 epic.
* Fix the parameters being passed for the assign constructor.
* Use assign::get_instance() instead of assign::get_context() to fetch
the assignment instance's properties.
Remove creation of calendar events for mod_assign with
eventtype = 'open'. Since mod_assign instance creation only creates a
calendar event for the due date, there's no point in creating an override
event for an event type that does not exist.
Set the event priority of the following activity overrides:
* mod_assign
* mod_lesson
* mod_quiz
Always create separate events for start and end dates of activities.
Damyon Wiese