AMOS BEGIN
CPY [relativedatessubmissionduedateafter,mod_assign],[relativedatessubmissionduedateafter,core_course]
CPY [relativedatessubmissionduedatebefore,mod_assign],[relativedatessubmissionduedatebefore,core_course]
AMOS END
Hidden courses can be used for training
but we do not want to generate insights for them
because students do not have access to hidden courses.
This was fixed in MDL-66806 for "Students at risk" model.
Fixed for "Students who have not accessed the course recently" in this issue.
* When completion tracking is not enabled for the course, it does not
make sense for the course's showcompletionconditions setting to
be set according to the default value indicated by the
"moodlecourse | showcompletionconditions" admin setting. Setting
showcompletionconditions as enabled when completion tracking is disabled
makes even less sense. So in such a case, we should not be setting a
default value for showcompletionconditions and allow it to be null.
* When the course is edited and completion tracking is enabled, this
also would set the "Show completion conditions" field to default to the
value set in the "moodlecourse | showcompletionconditions" admin
setting.
Render the activity information output component in the course homepage
only if either completion details or activity dates are to be displayed.
This can help reduce the number of files being included when loading the
course homepage (e.g. the activity information template for each
activity in the course homepage).
* Make sure the activity is visible to the user (cm_info::uservisible)
before showing the activity completion information.
* Add to-do status for overridden automatic completion
* Check the activity dates on the course homepage depending on
the value of the showactivitydates course setting
* Plus use the new Behat steps for checking activity dates
* activity_date_in_activity_should_contain_text()
- Checks the presence of the given text in the activity's date info.
* activity_dates_information_in_activity_should_exist()
- Checks the presence of activity dates information in the activity
information output component.
* activity_dates_information_in_activity_should_not_exist()
- Checks the absence of activity dates information in the activity
information output component.
* Add activity name for completion conditions labels. This would give
better information to screen reader users the activity that the list
of automatic completion conditions belong to. This would be useful
especially when the completion conditions are displayed on the course
homepage.
* Add data-region attributes to activity dates and completion
information divs.
* Reorganise activity dates and completion information divs so they
are only rendered when they have data to show.
Deprecate \core_course_renderer::course_section_cm_completion(). It is
not being used anymore and is being replaced by
\core_renderer::activity_information().
When an activity has manual completion tracking, pressing the manual
completion checkbox reloads the page after toggling the completion
state when the activity is linked to availability conditions.
The "Mark as done" button needs to mimic this behaviour as well.
The approach being taken here is to add a core_course/view JS module
for the course homepage which listens for the manualCompletionToggled
event and reloads the page when the activity module has availability
conditions tied to it.
Perhaps for future development, instead of reloading the page, the
container of the restricted course sections/activities can reloaded via
AJAX as well.
With the activity information output component dealing with the
completion information of the activity, there's no need to pass
completion info to the cm_format renderable.
Use the activity information output component to render activity
completion details and activity dates for activities on the course
homepage.
Includes fixup from Shamim Rezaie <shamim@moodle.com>
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.
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 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.
The current ->setMethods() has been silently (won't emit any
warning) in PHPUnit 9. And will stop working (current plans)
in PHPUnit 10.
Basically the now deprecated method has been split into:
- onlyMethods(): To point to existing methods in the mocked artifact.
- addMethods(): To point to non existing (yet) methods in the mocked
artifact.
In practice that means that all our current setMethods() calls can be
converted to onlyMethods() (existing) and done. The addMethods() is
mostly useful on development phases, not final testing.
Finally note that <null> isn't accepted anymore as parameter to
double all the methods. Instead empty array [] must be used.
Link: https://github.com/sebastianbergmann/phpunit/issues/3770
