AMOS BEGIN
 MOV [completionpass,mod_quiz],[completionpassgrade,core_completion]
 MOV [completionpassdesc,mod_quiz],[completionpassgrade_desc,core_completion]
 MOV [completionpass_help,mod_quiz],[completionpassgrade_help,core_completion]
AMOS END

We update the dates with user/group overrides. The calculation of
the override in the quiz module is different from the assignment
module as the quiz_overrides table des not have a sortorder column.
See quiz_update_effective_access().

AMOS BEGIN
 CPY [grade,core],[gradenoun,core]
 CPY [grade,core],[gradeverb,core]
AMOS END

Shamim Rezaie authored Mar 25, 2021 and Michael Hawkins committed Apr 07, 2021

Custom rules are combined using the AND operator. However, the
'completionpass' and 'completionattemptsexhausted' rules are exceptions
because they are combined together with OR, and form a single new rule
that then will be combined with the rest of the rules using AND.
This commit combines the mentioned rules into a single rule named
'completionpassorattemptsexhausted'.

Shamim Rezaie authored Mar 25, 2021 and Michael Hawkins committed Apr 07, 2021

The mod_quiz_get_completion_active_rule_descriptions() function was not
returning the description for the 'completionminattempts' rule. Added
that.

This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.

Since the class has only just been added to Moodle, now is a good
time to move it.

This reverts commit 9d58d4de, reversing
changes made to 535c0277.

In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).

Applying filters on an activity module description when using it as a
new calendar event's description is bad m'kay? We need to store the raw
text and apply the filters only when we actually display the text. That
way, filters (such as multi-language content) may actually fully work
and we do not initialise the theme and output machinery.

Additionally, we need to explicitly set the format of the description
text to HTML (because we have converted it to it already). Otherwise it
defaults to the current user's preferred editor format.

This is still a pragmatic hot-fix solution. The proper solution would be
to pass the raw text, format and embedded files.

Replace it for correct property_exists() when the element
being inspected is a property of object/class.

Amended and squased changes:
- keep mongo unmodified. The information is array, hence correct.
- fix a couple of messaging phpdocs that were incorrect.

Amended take#2:
- As far as mongo resturns BSONDocument that is ArrayObject, aka
implements ArrayAccess, we have decided to explicitly cast results
to array so existing array_key_exists() and other accesses will
continue working the same.

When some activities are manually completed by students, some are still showing in students' timeline.
This commit fix that for module assign,chat,choice,feedback,lesson,quiz,scorm and workshop.

When grades are deleted, it needs to know the context so any files
in the gradebook can be deleted. This means module delete_instance
functions must delete the grade_item before they delete the module record.

* Updated unit tests to account for participants

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.

Activities should not require the user manipulating them to have
calendar capabilities for their events to be added to the Moodle
calendar