When an automatic completion condition may have had its state change,
we now unset the cached value for the user's completion in the relevant
activity, so up-to-date values are re-fetched and available to students.
The previous behaviour was that custom conditions would remain cached
until the activity reached overall completion.
Provide page for the reports in the course administration.
The page has a drop down to navigate to different reports.
The navigation is remembered just like the grade reports in
the course.
Signed-off-by: Sujith Haridasan <sujith@moodle.com>
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 engine error messages changed
- some warning levels changed
- the carriage return symbol randomly appears
- one phpunit assertion fails and not really representative of anything
Create a new profile field type, move all existing content of the fields
'icq', 'skype', 'aim', 'yahoo', 'msn' and 'url' in the mdl_user table to
theses new profile fields if needed.
AMOS BEGIN
MOV [aimid,core],[aimid,courseimage,profilefield_social]
MOV [yahooid,core],[yahooid,profilefield_social]
MOV [skypeid,core],[skypeid,profilefield_social]
MOV [icqnumber,core],[icqnumber,profilefield_social]
MOV [msnid,core],[msnid,profilefield_social]
MOV [webpage,core],[webpage,profilefield_social]
AMOS END
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.
If a H5P content-type is disabled:
- The content bank won't display existing contents having it as a
main library.
- The content bank won't allow to create new contents using it.
Try to correct broken ul/ol/li tags, as they have an outsized impact
on course layout. Uses basic regex and loops to track open and closed
tags.
Also adds a deep clean option to the HTML cleaner, that runs less
frequent, more intensive cleanings. This is because normally _cleanHTML
gets called after each keystroke, which could cause problems with
large content on weak systems.
Behat changes are a fix for setting multiline strings in Atto, and
creating a multiline match step.
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.
Note that there wasn't any case of multiple testcase classes in
1 file. All the cases reported in the issue were false positives
caused but other "mock/fixture" files being named _test.
So all this issue does is:
1) rename any _test suffixed class in test files, because we are
going to start renaming a lot of test classes to _test.
2) ensure that the 2 test case classes modified in this issue,
are already observing the filename = classname rule that will
be implemented soon (and verigy it works).
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
We should be able to fetch the grade completion status for modules
that do not have custom completion configured. This also improves
unit testing coverage.
* 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.
