GitLab

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.

This involves a few changes:
- The callback is still called by the repository but only if the
replacement callback get_course_content_items is not implemented.
- Debugging is called when the get_shortcuts callback is called.
- We leave lti's implementation of get_shortcuts alone, in order to
maintain the output of get_module_metadata during its deprecation life
span.

Part of MDL-66074

The requesting user is not always the same as the current user. The container class now allows a different user
to be set as the requesting user. All capability checks are done against the requesting user.

Also, the $requestinguser is passed to core_calendar_provide_event_action and core_calendar_is_event_visible
callback functions. These callback functions need to be updated in all activity modules to accept a $user parameter.

The notice is explicitly repeated for activity modules because they
usually process user data heavily.

Allow modules to apply format_text() on user input before calling cm_info::set_content(). This is useful for
modules that add interactive content (for example, JS enhanced folder tree). Otherwise all javascript would
be removed if $CFG->forceclean is enabled.

The new setting will allow to host the temporary backup files
into a specific target directory. Defaults to '$CFG->tempdir/backup'.

Calling make_backup_temp_directory() checks that the required sub-directory
will be properly created under the new target directory.

See mod/upgrade.txt for explanation.

Part of MDL-59313.

We should indicate the API changes for developers.

First stage deprecation for the functions update_module_button and
core_renderer::update_module_button().

also deprecate callback get_types()

Mainly to verify groups visibility this new callback has been created.

Note this was originally 3 commits but for amending purposes they have
been squashed.

In order to avoid confusion with the new scorm_view fuction

This was forgotten in MDL-49101.

* Upgrades existing data so that the groupmembersonly option is
  replaced with equivalent data for the new availability API.
* Removes the database field and admin setting used for
  groupmembersonly.
* Changes core modinfo library to remove/deprecate groupmembersonly
  data and functions.
* Changes other core library files to remove groupmembersonly
  references.

Includes deprecation of several functions, listed in lib/upgrade.txt.

AMOS START
 MOV [neverseen, mod_folder],[neverseen, report_outline]
 MOV [neverseen, mod_page],[neverseen, report_outline]
 MOV [neverseen, mod_resource],[neverseen, report_outline]
 MOV [neverseen, mod_url],[neverseen, report_outline]
AMOS END

In new logging api, xxx_get_view_actions() and xxx_get_post_actions()
will not be used to identify the paticipation of user. Event's crud
and edulevel status will define user's participation.

It is already in the main lib/upgrade.txt but it should be mentioned here as
well.

MDL-22999 core_grades: Added ability to configure maximum grade value both globally and for each graded-activity.

* Added new constant: MOD_SUBTYPE_NO_CHILDREN
* When MOD_SUBTYPE_NO_CHILDREN is returned from xxx_get_types()
  then default display is used for activity chooser.
* Updated mod/upgrade.txt
* Removed dead code from navigationlib.php instead of updating
  it for new behavior of xxx_get_types
* Updated lib/upgrade.txt

* FEATURE_USES_QUESTION_BANK is now a module_supports flag which declares
  that an activity uses the question engine.

* question_module_uses_questions can be used to determine if a module
  uses the question bank.