We modified calendar_get_events in a non backwards compatible way
so instead of fixing that, an easier approch is to simply revert
it to the 3.2 implementation. This should be fine since the way
to get events is going to change in an upcomming release, and we
had to swap all occurences of calendar_get_events in core with
calendar_get_legacy_events to make sure the calendar and overview match.
Prior to this patch, if a user was in two groups, and an override
existed for both groups in an assignment the override
visually lower on the override list would be displayed on the
overview, whereas the one visually higher would be displayed
in the assignment grading table.
* Move and rename \core_calendar\local\api::get_legacy_events() to
calendar_get_legacy_events() in calendar/lib.php.
* Fix the parameter-normalising callback function in
calendar_get_legacy_events() so that it correctly handles false values
by returning an empty array instead of it returning a non-empty array
that contains an empty element.
If there are multiple, non-repeating events with the same module name,
instance and event type. The most specific event or the event with the
highest priority will be shown.
The ordering of event priorities:
User override events > Group override events > Course events.
If there are no user override events and there are multiple group
overrides for an event, then the one with the highest priority will be
shown.