The scopes parameter should be passed when creating the OAuth2 badges
client. As it is an optional parameter, when it's empty, it will
be initilised with the supported scopes for the backpack issuer.
It will happen, for instance, when a call is done to oauth2callback.php
because, as defined in RFC6749, OAuth2 authorization response only
supports code and state.
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.
* activity_completion_condition_displayed_as()
- Shows the status of an automatic completion condition for a given
activity
* activity_should_have_the_completion_condition()
- Checks that the activity displays the given completion condition
* manual_completion_button_displayed_as()
- Shows the status of the manual completion button for a given
activity
* the_manual_completion_button_for_activity_should_be_disabled()
- Checks that the manual completion button for the given activity is
disabled.
* there_should_be_no_completion_for_activity()
- Checks that the activity does not show completion information
* toggle_the_manual_completion_state()
- Toggles the manual completion button's state for a given activity
* overridden_manual_completion_button_displayed_as()
- Checks the manual completion state of an activity.
* overridden_activity_completion_condition_displayed_as()
- Checks if the activity with specified name is maked as complete.
* 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>
That way we can check that the expectations are
working ok for every database. Previously only the
ANY case was being tested.
Also, convert them to course badges and check, via
review_all_criteria() that the SQL structures returned
by award_criteria_cohort->get_completed_criteria_sql()
doesn't fail and return the expected counters.
