Until Moodle 4.0, renderer.php file was optional (although highly recommended)
for course formats. From Moodle 4.0 onwards, renderer is required to support
the new course editor implementation.
The legacy_format_renderer class has been created for backward compatibility,
to avoid some errors with course formats (such as social) without the renderer
file. Apart from that, course_format->get_renderer() method has been reviewed
to use this legacy_format_renderer when no renderer.php file is found.
The deprecated method to render the dropdown based activity chooser
from 430746d3 was still being called, which produced debugging on
the site when doing so.
The `types` object introduced in Moodle 3.11 has been replaced with the
`eventTypes` object which is used consistently across all CustomEvent
definitinos.
Likewise the trigger functions have been renamed from
`triggerUploadStarted` to `notifyUploadStarted` and from
`triggerUploadCompleted` to `notifyUploadCompleted`.
Backwards compatability is maintained.
It seems that the new phpcs3 checker is now controlling those
line comments that previously were ignored.
This commit just looks for all the cases and bulk-add
them when needed. The bash script (mac) used to add all them is:
while read -r line; do
arr=(${line//:/ })
if [[ -n ${arr[0]} ]] && [[ -n ${arr[1]} ]]; then
echo " file ${arr[0]}, line ${arr[1]}"
sed -i "${arr[1]}s/\$/\./" ${arr[0]}
fi
done < <(find . -name version.php | xargs ag --nomultiline '>(version|requires) *=.*//.*[^;\.]$')
* The button to "Add group/grouping access restriction" under
common module settings should only be present if corresponding
availability plugins are enabled; and
* Prevent the same button behaving as a submit button, which
intercepted the user hitting return in the form and added a
restriction without deliberate action taken by the user.
This is just to make Behat tests to pass. There is a bug
discovered MDL-71382. We will address that tracker after 3.11
release. For now we just replicate stables behavior.
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.
