- added class format_base as the base for all course formats
- added class format_site for the pseudo-format 'site' used for displaying activities on the front page
- added class format_legacy that overrides format_base functions with calling old-style 'callback_xxx' functions
- replaced all usage of 'callback_xxx' functions with format_base methods
- made arguments of get_section_name(), get_course_url() more flexible
- deprecated function get_generic_section_name(), it's contents is moved to format_base
- global_navigation::format_display_course_content() is removed, plugins can supress the sections navigations using extend_course_navigation()
The problem is to do when you pause a bit, so a search starts, and then
type a bit more before the search finishes. It was behaving like this:
1. Type a bit, then pause.
2. First search request sent.
3. Type a bit more, then pause.
4. Second search request sent.
5. First search request completes.
6. You try to select one result.
7. Second search request comples, overwriting what you are selecting.
This fix works by cancelling the first request before sending the
second.
This only matters in an obscure edge case, but it is an edge case we hit
with one of the OU question types.
This load data code is processing the results of a LEFT JOIN, so is_null
is the correct logic.
This affects the subquestions that appear as an embedded text input box.
There are three cases:
1. Input for subq left blank
2. Input for subq was wrong, and matched by a * wildcard.
3. Input for subq was wrong, and did not match any answer.
2. and 3. should look identical, apart from any feedback in case 2.
1. is different. The state should be displayed as "Not answered" even
though the mark for this part is still shown as 0.
There are some new unit tests for these cases.
Also, we slighly improve handling of , for decimal point in multianswer,
although there are still issues.
While working on this, I made some minor clean-ups in shortanswer and
numerical qtypes.
This commit coverts everything in the codebase to use the new
users_order_by_sql function when sorting lists of users. More details in
the bug.
Note that this does not change places where users are displayed in a
sortable table, and the sort order comes from the table.
The purpose of this method is to ensure that when we display lists of
users in different places, the default sort order is consistent.
Having this code centralised in one place them makes it possible to
improve things accross the board, and there is an example of that here.
There is logic so that if we are searching for particular string, then
users with an exact match are sorted first.
