-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
3.4.1
-
MOODLE_34_STABLE
-
It seems that calendar export does not include group events, even if the "all events" or "events related to groups" export types are selected.
This appears to be because of the following code in get_raw_events_legacy_implementation in calendar/classes/local/event/strategies/raw_event_retrieval_strategy.php:
// Get the user's courses. Otherwise, get the default courses being shown by the calendar.
$usercourses = calendar_get_default_courses();// Set calendar filters.
list($usercourses, $usergroups, $user) = calendar_set_filters($usercourses, true);
When calendar_get_legacy_events is called from calendar/export_execute.php, it seems that it is expected that it will get all events for the users, groups, and courses specified.
However, calendar_get_legacy_events calls \core_calendar\local\api::get_events, which calls \core_calendar\local\event\data_access\event_vault::get_events, which eventually calls \core_calendar\local\event\strategies\raw_event_retrieval_strategy::get_raw_events.
From apt::get_events onward, it is clear that the users/groups/courses params are treated as filters rather than as lists of what to retrieve.
Since the calendar_get_default_courses function assumes that USER is set appropriately (and it isn't, as export_execute uses an authtoken to authenticate and then thinks it can specify what should be retrieved), this ends up causing usergroups to be empty, and no group events to be retrieved.
I think the easiest fix would probably be to ensure USER gets set properly in export_execute before calling calendar_get_legacy_events.
I'm astonished that nobody else seems to have noticed this; it looks like it must have been this way since some time in the development of 3.3. So, what am I missing?
- is duplicated by
-
MDL-58768 Calendar API has a hidden dependency on the logged in user
-
- Closed
-