Now that subscriptions and exports are accessed from the same page which
is linked as "Import / export calendars", there is no need to have a
separate "Export calendar" link.
* Store the view mode of the calendar in the calendar_information
object.
* Let the month exporter handle the production of context data by
moving 'viewingmonth', 'showviewselector', and 'viewinginblock'
inside it.
* Set the proper calendar view mode in the core_calendar/month_detailed
template.
* Pass the calendar view mode to the
core_calendar_get_calendar_monthly_view WS function.
Done by:
* Designating instance IDs for each month_exporter instances and
assigning these instance IDs in templates.
* Adding the instance ID as an optional parameter for the
core_calendar_renderer::course_filter_selector() to generate
course filters with unique element IDs.
* Move 'calendareventtype' property to event_exporter_base and
rename it to 'normalisedeventtype'
* Add a 'normalisedeventtypetext' property to event_exporter_base
for displaying the human-friendly text for the normalised
event type.
* Clean up calendareventtype from other exporter/template locations
* Fix template names.
The methods get_module_timestamp_min_limit() and get_module_timestamp_max_limit()
are doing generic stuff and can be used for other calendar event types as well.
I have renamed them to get_timestamp_min_limit() and get_timestamp_max_limit() respectively.
When clicking on an event in the month view, a modal opens with
information about it. That modal did previously only show the start time
of the event. It now also shows the end (if the event has one).
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.
Stopped the JS from running on the block when the user is not logged in
because it attempts to load a summary modal when an event is clicked on
which results in a failed call to a webservice.
Simey Lameze