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.
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).
In MDL-70689, Eloy and Helen suggested some fixes to improve this patch.
As this is a followup issue to move the pending services, this
very first commit will fix pending things raised in the parent issue.
They are thrown in the following circumstances:
* The dynamic form class doesn't exist;
* It does exist but it's `check_access` method throws exception
Co-Authored-By: Andrew Nicols <andrew@nicols.co.uk>
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.
