It was more than 8 years since we wrote in that format.

Helen Foster authored Sep 04, 2018 and David Mudrák committed Sep 04, 2018

Significant string changes:

* completionpass_help, gradetopassnotset in mod_quiz - grade to pass set
  in quiz settings not gradebook
* namecolumnmissing,core_cohort - fixing incorrect message about adding
  users to a cohort

Merge branch 'MDL-55744-master_atto_should_not_autosave_on_not_loggedin_users' of https://github.com/dravek/moodle

Changes include:
- MySQL 5.6 is required.
- PostgreSQL 8.4 is required.
- Oracle 11.2 is required.
- 64bits architecture is recommended.

Make sure that the autcomplete input field is wide enough to display the
placeholder text.

The form-autocomplete module uses three Mustache templates
core/form_autocomplete_input, core/form_autocomplete_suggestions and
core/form_autocomplete_selection. However, it did not support executing
the JS that is eventually part of those templates.

Mark Johnson authored Nov 17, 2017 and David Mudrák committed Aug 31, 2018

This allows the teacher to define what students are supposed to submit
(online text and/or attachment) and if the given submission part is
required or optional.

Before this patch, we only checked that the given provider has been
configured in the user or system preferences. However, if the provider's
component is disabled, it does not even appear in these preferences.
Additionally, there was no check that the message / notification
provider is among providers allowed to be consumed by the recipient.

The patch checks that the message origin is among providers returned by
the message_get_providers_for_user() so disabled plugins can't act as
sources of messages and users can't receive messages from providers they
do not have capability for. This mitigates the risk of abusing a plugin
as a source of spam, for example.

Unit test is fixed and extended. When the $CFG->messaging is disabled,
no messages between users should be sent (I can't understand why the
unit test was written in an opposite way). Added assertions for the
raised debugging message.

During the calendar work, we have added the feature of
drag and drop activity event or "action events".

The problem at that time was, action events could not be
editable through the calendar UI, but should be allowed
to drag and drop. So, we couldn't use the return of
calendar_edit_event_allowed() because it can return true
(in case of teachers, that have permission to change the
activity) and the attribute isactionevent was created to
control on the UI if the user is viewing an action event.

So what my patch does is just add the check if we are
viewing an action event, and in this case, it won't display
the cog to edit that event.

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

The completion API should not require a user to have the capability to
add calendar events for it to function correctly.

When a user does not have calendar capabilities completion dates should
still be created correctly.

The action menu was missing from many of the database activity pages,
which meant that it could not be accessed until enough had been done to
the activity to make the editing tabs that used view.php accessible.