This implementation will introduce a qbank plugin
"deletequestion" which will implement the delete question
action in the question bank view by replacing the core
class. Having this plugin will give users the
flexibility of enabling or disabling this action.
The course unit test assumes the number of db call. This assumption
is correct in vanilla moodle only. Once some plugins installed their
observers may do extra db calls. Due to caching the number of actual
db calls in the unit test may be fewer.
This commit implements the qbank api so that any plugin
can implement its own question bank. This api currently
works parallely with the moodle core classes and the
added qbank in the core, means the moment a plugin
is installed, that object is replaced with the object
from the plugin instead of core, which means the api
has flexibility till the plugins are integrated and the
plugins can be integrated in any order.
All the old classes are still there and not deprecated
as there is a different tracker for the changes to the
quiz and another tracker for class deprecation and
class renaming. Core question units tests are pointing
to the new api structure but the classes are pointing
to the location related to the plugin availability.
Co-Authored-By: Luca Bösch <luca.boesch@bfh.ch>
Co-Authored-By: Guillermo Gomez Arias <guillermogomez@catalyst-au.net>
one more array fix
This commit implements the qbank plugin type which
includes the boilerplate for the qbank plugin, the
qbank plugin management admin page and required core
code addition.
Movement of classes to classes/local/bank and additional
todo addition to all the existing ones to align with
future tracker for class renaming. This commit does not
contain any class renaming of the old or deprecated
classes. MDL-72004 will be used to rename, remove or
deprecate old classes after integrating all the qbank
plugins.
There were existing places each doing its own checks similar to the ones
covered by the newly added core_user::awaiting_action() method. This
patch replaces those custom checks with this new API call.
Fetching user tours used to fail on external_api::validate_context() and
require_login() calls if the user did not have the site policy agreed.
The patch introduces a check to see if the user is fully set up and
ready to use the site before attempting to load the tours.
The method allows to check if the user is fully ready to use the site or
whether there is an action (such as filling the missing profile field,
changing password or agreeing to the site policy) needed.
