* 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
* 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.
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.
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.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
Makes sure the guest user context exists when fetching
the recommended modules. If the context does not exist
an exception is being thrown describing the problem.
When plugins are removed from disk, an exception is thrown when
calling component_callback_exists.
This exception should be catched here in order to load properly
the activity chooser (otherwise, the exception will be displayed
and no activity will appear).
Padding nested course categories by space to make them render in a tree
structure does not really make a lot of sense as they are already being
rendered as full paths. It's simpler to show them without the
indentation.
Given this, there's not much point keeping make_categories_options().
So it's better to deprecate this function and call
core_course_category::make_categories_list() directly instead.
* Added aria-label for category single select element when on Courses
view mode.
* Fix correct labelling of custom control checkboxes. Instead of adding
aria-label in the label element, add an sr-only span within the label.
* Remove inappropriate 'group' role for the list of courses.
The list of courses is not being rendered as a tree structure
so adding a 'group' role to the list of courses is not really
necessary.
* Add aria-label for the search courses field.
* Add legend for the search courses fieldset.
* Use the primary colour for the category selection highlight instead
of the info colour.
* Changed the labels for the up/down icons using moveup/movedown
lang strings.
Deletion form offers user a deletion with contents move option, it is
available when full deletion is not permitted. Action menu should take
this into account too and allow user to reach the form.
If you try to visit a category where another user is deleting a
course the coursecat cache may not be fresh. This is because there
is a breif time where the course record will have been deleted,
while it is deleting other course information, before the event that
triggers the coursecat cache to be purged is fired.
This patch adds better core support for copying courses.
There is now a simplified and dedicated UI for copying
courses. This can be accessed from the course context
menu or course management screens.
All backups are done asynchronously and there can be multiple
copies of a course in flight at once.
Introduce new hooks for plugin developers:
- <component>_can_course_category_delete($category)
- <component>_can_course_category_delete_move($category, $newcategory)
These hooks allow plugin developers greater control over category deletion. Plugin can return false in those
functions if category deletion or deletion with content move to the new parent category is not permitted.
- <component>_pre_course_category_delete_move($category, $newcategory)
This hook is expanding functionality of existing <component>_pre_course_category_delete hook and allow plugin developers
to execute code prior to category deletion when its content is moved to another category.
- <component>_get_course_category_contents($category)
This hook allow plugin developers to add information that is displayed on category deletion form. Function should
return string, which will be added to the list of category contents shown on the form.
