When a question bank is created by the system, it's name may be created
by combining a course of category name with a language string. If the
course name is already near the limit for its database field, the
resulting question bank name may be too long for that field, and cause
an error.
This implements a function for generating question bank names which will
trim string parameters down until the resulting name is below the
allowed length. It also implements some validation to prevent
manually-created banks with names that are too long.
- Adds the "cat" field to the converted legacy filter, which was
missing.
- Does the conversion on the editrandom.php page as this was
throwing a warning.
When a quiz that used shared questions was being restored without the
qbank the questions came from, if the qbank still existed on the target
site, the restored questions were being left in a category in an invalid
course context.
This changes the process so that if the original qbank does exist and
the user can access to it, we will find any references to the restored
copies of questions from that qbank, switch them to refer back to the
original qbank, then delete the category they were restored to from the
course context.
If the user does not have access to the qbank, a new one will be created
in the target course and the questions moved there, just as if the
original qbank did not exist.
Previously, question categories which contained only questions with no
usages were deleted during migration to mod_qbank.
Also, contexts that contained no questions once unsused questions were
deleted were still migrated to a mod_qbank instance, which was empty.
The intention is that hidden questions with no usages should be deleted,
then any categories which are now empty should be deleted rather than
migrated. If there are no categories that contain questions left in a
context, creation of a mod_qbank to migrate those categories is not
necessary.
The unit tests did not cover the cases of categories containing only
non-hidden questions without usages, of categories containing only
unused questions with multiple hidden versions, or of empty categories
with children that were not empty.
This change now specifically checks whether a category or is children
are empty before deleting the category, rather than checking question
usage, since stale questions (hidden questions with no usage) are
already deleted before this point. It also expands the unit tests to
cover the above cases.
This makes the rendering of the question comments count additionally
check the core moodle/comment:post capability, since this capability
is required to make comments. Previously, this was not being checked
so users could open the modal to make a comment, which was causing
a javascript error due to expected elements being missing.
- Add .visually-hidden to the Boostratp 5 bridge SCSS file
- Replace .sr-only occurrences with .visually-hidden
- Replace .dropzone-sr-only-focusable with .dropzone-visually-hidden-focusable
for consistency
This makes the tags which are available to the user on the question
bank tag filter, use tags from all available contexts, not just
that course. This means they can filter by tags assigned to system
questions as well, for example.
This adds a new question bank filter for filtering by question type. The
filter can be applied with one or multiple question types, and can
either include or exclude the selected types.
This corrects some definitions of the methods in the base condition
class to make things more obvious to developers implementing new
filters.
Previously if your filter wanted to use the default
`core/datafilter/filtertype` class, you still had to implement
`get_filter_class` to return `null`, since it was declared as abstract.
This change defines it as returning `null` by default, so this is no
longer necessary.
Also, this removes the default definitions for `get_condition_key` and
`build_query_from_functions`, and declares them abstract. Currently it
is necessary to override these to implement a functional filter so it
doesn't make sense to have a useless default definition.
This will not cause any breakages with existing filters. All filters
must already be defining the methods that are now abstract, otherwise
they will not function. Any filter that is now overriding
`get_filter_class` to return `null` will continue to work as before,
even though this is no longer necessary.
