When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
AMOS BEGIN
CPY [relativedatessubmissionduedateafter,mod_assign],[relativedatessubmissionduedateafter,core_course]
CPY [relativedatessubmissionduedatebefore,mod_assign],[relativedatessubmissionduedatebefore,core_course]
AMOS END
This commits adds a fallback for plugins which does not have
custom_completion implementation.
For those cases, it will search for {modulename}_get_completion_state
callback in the plugin and call get_overall_completion() method in
cm_completion_details class to get the overall completion state for
a course module and user.
Create a new profile field type, move all existing content of the fields
'icq', 'skype', 'aim', 'yahoo', 'msn' and 'url' in the mdl_user table to
theses new profile fields if needed.
AMOS BEGIN
MOV [aimid,core],[aimid,courseimage,profilefield_social]
MOV [yahooid,core],[yahooid,profilefield_social]
MOV [skypeid,core],[skypeid,profilefield_social]
MOV [icqnumber,core],[icqnumber,profilefield_social]
MOV [msnid,core],[msnid,profilefield_social]
MOV [webpage,core],[webpage,profilefield_social]
AMOS END
If a H5P content-type is disabled:
- The content bank won't display existing contents having it as a
main library.
- The content bank won't allow to create new contents using it.
* 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.
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.
Final deprecation for constant BADGE_BACKPACKURL (it has been removed)
and badges/backpack.js file (it has been removed too).
Besides, some methods have started the deprecation process too:
- badges_check_backpack_accessibility
- badges_setup_backpack_js()
- badges_local_backpack_js()
Apart from that, string 'addbackpack' has been deprecated here
because it's not used anywhere.
We used to display capabilities like "Manage any calendar entries",
"Delete evidence", "Manage competency frameworks", "View hidden courses"
and others as "Missing capabilities" for the mobile app service tokens.
This gave dangerous impression that the app will not work for students
without these capabilities granted. There are known cases of admins who
started to grant all these caps to the Authenticated user role because
they were afraid the app would not work for them.
The problem here is that the official mobile app service includes some
functions that have these capabilities declared as required. But they
are not really required to use the app. Either the app makes its own
clever checks of capabilities before calling the functions, or sometimes
the capabilities are not even correctly declared.
It is safer for everybody to display this information for custom
services only where the risk of the falsely missing caps is lower and
the information is more accurate.
Also, the help text has been improved so it does not suggest that these
capabilities must be always added. We do not know why the service has
them declared. In some cases, a service has capabilities declared just
because it makes use of them in the if-then fashion.
Additionally, the patch also displays the service short name because it
is actually needed to know.
The patch adds ability to filter the list of token by the token value,
the user and the service. Also the button to create a new token is made
more prominent and easier to spot.
