When calling the calendar_get_allowed_event_types function with
no course id, it is supposed to return true if you have the
relevant permissions in any course.

For users who have the managegroupentries permission, this was not
the case - even though it works correctly if you call the function
with a supplied course id.

This change makes behaviour with and without a supplied course id
consistent.

David Monllaó authored Apr 05, 2019 and Eloy Lafuente committed Apr 09, 2019

The patch includes changes applied after the peer review.

The location is now updated in repeated events if it is altered in one
event and the option 'Also apply changes to the other X events in this
repeat series' is selected. If the location is not altered but some
other details, then manual changes of the location in other events
will not be overriden.

Also rename course_in_list -> core_course_list_element
Deprecate class coursecat_sortable_records

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.

Decoupled calendar_set_filters from $USER.
Also removed the backward compatibility bit from the function because it was a left over.

This commit does few tweaks and other performance improvements to
calendar_get_allowed_event_types to be more efficient. Also some minor
queries optimizations on the event form to fetch the list of courses
without groups.

Replace calls to \coursecat::get_all() or cache the results.

Stop loading the context in the constructor if it hasn't been provided.
There is no need to load it by default. We should lazily load it when it
is required.