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.
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.
The activity information output component displays information about
an activity module that can contain:
1. Activity dates
2. Completion information
a. A manual completion button; or
b. A list of automatic completion conditions and their statuses.
This patch also includes a new JS module called
core_course/manual_completion_toggle for toggling the
completion state of activities that support manual completion.
Allow the core_completion_update_activity_completion_status_manually
web service function to be called from AJAX as well. This is needed
by the new manual completion toggle button in the
core_course/completion_manual template.
Before resetting completion states during module update, we need to
rebuild the course cache first in order to properly reset the completion
states. Otherwise, calls to methods that fetch course module info
via cache (e.g. cm_info::create()) will fetch outdated information.
This change removes references in code and comments to a few
deprecated functions that were accidentally missed in the larger
change.
The code changes only affect service_users.php. I made it support
custom user profile fields in this query, because it was easy
enough, rather than adding another TODO to fix later.
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).