Current test works ok every day of the year but the day of
DST begin changes (last Sunday of March currently).
That day, 01:00 Europe/London simply doesn't exist, because
the time is moved forward by 60 minutes.
Hence the expectation for the next cron execution is not 1 "normal"
day (24h) but 1 less hour.
Note this only happens for the current test on DST begins, the
opposite change (DST ends), happening the last Sunday of October
is not affected, because, at all effects, 01:00 is a perfectly normal
and existing hour.
The machinery to fix orphaned calendar events that were broken by MDL-67494.
The solution consists of:
1) Upgrade step that checks if this site has executed the problematic upgrade steps and
if positive, it will schedule a new run for calendar_fix_orphaned_events adhoc task.
2) Adhoc task that will self-spawn calling the recovery machinery, running until
all the orphaned calendar events are fixed. It also sets the maximum runtime of
60 seconds. It is also possible to override that number by specifing the desired
number setting the ->calendareventsmaxseconds in your config.php
3) CLI script that will look for all the calendar events which userids
where broken by a wrong upgrade step, affecting to Moodle 3.9.5
and up.
It performs checks to both:
a) Detect if the site was affected (ran the wrong upgrade step).
b) Look for orphaned calendar events, categorising them as:
- standard: site / category / course / group / user events
- subscription: events created via subscriptions.
- action: normal action events, created to show common important dates.
- override: user and group override events, particular, that some activities support.
- custom: other events, not being any of the above, common or particular.
By specifying it (--fix) try to recover as many broken events (missing userid) as
possible. Standard, subscription, action, override events in core are fully supported but
override or custom events should be fixed by each plugin as far as there isn't any standard
API (plugin-wise) to launch a rebuild of the calendar events.
4) Unit tests and helper functions to generate calendar events. We have decided to
keep the tests simple, testing only true and false and not using data generators because
the code is purely to recover the calendar events and won't turn into an API or something
and also due to the urgency of this issue.
The helpers have been created in calendar/tests/helpers.php since there are no data generators
for calendar.
Some recent tests do set a date time element
to ##now## or tomorrow and, immediately after that
the look if, effectively, ##now## and #tomorrow#
have been set (with minutes resolution).
Problem is that, between the field is set and the field
is verified, it can happen that the time advances to
next minute (from H:M:59 to H:M+1:00) and then the
assertion fails.
To avoid this, we could have lowered the resolution to be
hours... but that doesn't solve the problem just makes it
to happen less often.
So, instead of that... we are setting the 2 now and tomorrow
cases to be "today noon" and "tomorrow noon" (12:00:00) so
we ensure they won't be ever in the risk of jumping of minute.
By rounding the current time it was possible that the most recently
created user enrolments (e.g. self enrolments) were being excluded.
This would manifest itself in a user being enrolled on a course,
but it not appearing under "My courses" navigation or on their own
Dashboard until the rounded time had caught up with the current
time.
This includes 2 change to the order date(time) elements are filled,
each one addressing one type of problem, where current order is
problematic and can lead to unexpected dates.
1) Changing date, when current month only has X days and target
month has more than X days. Example, being 1 April, change
the date to 31 May.
This is solved by changing the order of introduction
from current D => M => Y to Y => M => D.
2) Changing date, when target month only has X days and current
month has more that X days. Example, being 31 March, change
the date to 28 Feb.
This is solved by always setting the D to 1, before the
Y => M => D sequence commented @ 1) begins.
Because of the order that dates and datetimes are filled by behat
sometimes there are some intermediate results that are impossible
and then the form (javascript) automatically reacts and fixes the
date, ultimate leading to a different date that the one we wanted
to set with Behat.
This is noticeable when switching between months (with some day
being the last day of the month) and the 2 months have a different
number of days. For example April date => March date (or the opposite).
This test covers all the critical changes (day, month and year),
back and forth. All times are Perth/Australia.
* Fixed inverted $sameuser test data.
* Fixed caching expectation check. Caching only relies on whether the
user accessing the completion data is the same user or not.
* Fixed checking for the caching of other modules. Should have been
checking cm ID and not instance ID.
* Additional test case when whole course parameter is passed as
true, but the requesting user is different from the target user.
These recursive calls didn't work in PHP 7.3 and below, but in PHP
7.4 they also cause a fatal error which means if you have invalid
availability data, the whole page might die.
Modifies the 'string time to timestamp' behat trasformation to use
userdate() instead of date(). The userdate() method is generally used
throught Moodle for constructing formatted date strings and this change
will provide more consistency and prevent any potential behat failures.
Therefore, if the date format is defined in the given trasformation, it
has to be strftime compatible. Example:
'I should see "##tomorrow noon##%A, %d %B %Y, %I:%M %p##"'
The unit tests for completion_info::get_data() does not make a lot of
sense with mocking being incorrectly used and the actual functionality
is not being properly tested. I have rewritten the test to use actual
cm_info instances and data providers for better coverage.
* Fix typo in $cm parameter's type in PHPDoc
* Improve the comment to better explain the logic why fetching the
completion data for the whole course can only be done when caching is
used.
Even if $wholecourse is set to true, there's no point in fetching the
completion data for all the course modules unless we're caching the
results.
Eloy Lafuente (stronk7)