This splits the API functions required for the reorganised category UI,
to properly separate the qbank_managecategories and core_question APIs.
This methods that were part of question_category_object that should live
in the core_question namespace (generate CRUD operations related to
categories) are moved to the new \core_question\category_manager class.
The parts that belong in the qbank_managecategories plugin as they are
used to display the editing UI are moved to the
\qbank_managecategories\question_categories class.
Static methods that were defined in \qbank_managecategories\helper and
were only used within methods that have been moved to one of the new
classes have been deprecated and moved to those new classes as well.
This will allow the entire
\qbank_managecategories\question_category_object class to be deprecated
in the following commit.
When the question custom fields were deleted, if there were any
hidden columns in qbank Column sort order referring those fields they
were throwing 'Custom field does not exist' exception. Changes done to
ignore such fields and display valid hiddencols, as these references
were breaking the qbank Column sort order and Question bank pages.
We need to pick the latest 'ready' version of each question
(not questions where the latest version is ready).
There are test of the behaviour of random_question_loader, and
then a test in the quiz to prove it works in use.
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
This changes the cache purge code to select IDs for deletion
first, rather than using a subquery in a DELETE, since this
risks causing a deadlock in MySQL.
Moves the data-filtercondition property to an element that always
exists regardless of whether the selected category from the filter
has questions or not. This will effectively solve the exception
that is being thrown due to the non-existing element and also
enable creation of random questions in a category that does not
have any questions yet. Also, the data-filtercondition attribute
is no longer used when creating a random question in a new category
as this value is not relevant in this case. Instead, a default
filter condition is generated in the webservice for the random
question based on the newly created category.
Chrome ignores min-width on table headers with table-layout:fixed,
meaning that question bank headers could be resized so that the controls
were overlapping, and could be too narrow by default.
This removes min-width: min-content in the headers and instead uses
Javascript to calculate a constrain a min width based on the content of
the headers.
This replaces the "Show question text in the question list?" filter, which was
never really a filter, with a new widget displayed alongside other question bank
controls like "Create a new question" and "Reset columns".
It also refactors the logic of displaying the question text field or not, so that
it is all handled within the qbank_viewquestiontext plugin rather than relying on
code in the view.
This modifies the question_data fragment used by the filter code to make its
parameters closer to the URL parameters of the question/edit.php page. This
Allows us to progressively enhance the add, remove and reset actions on the
question bank page, using this same fragment to reload the question table after
each change. This re-uses the same actions.js module used for enhancing these
actions on the qbank_columnsortorder admin screen.
This also resolves MDL-78829.
Some question bank plugins use a separate class for each plugin they
define. However, qbank_customfields (and potentially others in the
future) uses a single class to define multiple fields. Using the class
name as an ID for the column doesn't give us a way of reliable
instantiating an object for the column. Previously, qbank_customfields
appended the field name as though it was a namespaced class, but this
had to be manually constructed and deconstructed by detecting this
particular column class.
This change introduces a standard way of constructing a unique ID for
each question bank column, in the form
pluginname\columnclass-columnname. This ensures that the ID will be
unique for each column, and the ID can be used to instatiate the
column's object.
This changes the root element used by the fragment when
applying filters, so that the whole of display_question_list()
is reloaded.
This ensures that the returnurl will be updated correctly on the
question actions and bulk actions without manipulating then
further in Javascript.
If a quiz had a long job to calculate statstics running, this would
cause pages that may also attempt a recalculation (the statistics report
page or question bank) to load very slowly, and possibly result in a
database deadlock.
This change will firstly prevent the question bank page performing
analysis calculations at all, since these are not required for this
page, which will speed up loading and prevent deadlocks on this page.
Secondly, this adds a lock to the recalcuation process so that it cannot
run twice concurrently. This will present the user with a message to
indicate that it is waiting for a running calculation until it is
complete, and eventually it will timeout with a message and debugging.
We were experiencing problems caused by old stats analysis in our
database, computed when there was a bug, causing fatal errors
when they were displayed. Therefore, this code needs to be robust to that.
Since PHP 8.2, all properties on a class must be defined as the PHP
Dynamic Property feature has been deprecated.
This commit goes one step further and switches this class to using
constructor property promotion. This language feature has been available
since PHP 8.0 and allows for simplified creation of class properties
which are initially defined in the constructor.
It turns out that there are plugins which don't (currently)
clean up their question attempts when a context is deleted.
Therefore, we need to make Moodle core robust to that.
Ilya Tregubov