Custom fields can now be added to question types.
Site administrators can configure the custom fields and
filed types available. Teachers and question creators can
then use these fields for extra question metadata when
creating questions. Question creators can control if
the fields are displayed to students when they are
taking a quiz or not.
This features uses the core Moodle custom field API.
Co-Authored-By: Matt Porritt <mattp@catalyst-au.net>
Co-Authored-By: Safat Shahin <safatshahin@catalyst-au.net>
Co-Authored-By: Marc-Alexandre Ghaly <marc-alexandreghaly@catalyst-ca.net>
Apart from adding the new get_enabled_plugin($pluginname) method to the
core_plugininfo\base class, and overwritting it for filter, a bug in
enable_plugin in filter, introduced in MDL-72720, has been fixed too.
This one was tricky because it works slightly different and requires
a repository instance will be created if it doesn't exist.
For now I've implemented the easiest approach because it's not
possible to create instances (some extra parameters should be added
to the method in order to support it).
This one was tricky because it works slightly different and requires
a portfolio instance will be created if it doesn't exist.
For now I've implemented the easiest approach but, in the future,
it might be improved adding also the "deleted" status to the
enable_plugin() method, to completely remove it (current
implementation only switch status from "Enable but hidden" to
"Enable and visible").
This implementation will introduct changes to
the mod_quiz to implement the new qbank api
for view. Major changes are introduced in
the custom view and also all the legacy points
to the old qbank are changed to qbank plugins
where needed. It also deprecated and deletes
classes and scripts which were kept not to
break mod_quiz for the new api implementation.
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.
A new plugintype has been created for having more than one installed
third-party H5P libraries. Existing libraries have been moved from
lib/h5p to the new h5plib_v124 plugin.
* Plugins can now explicitly declare supported and incompatible Moodle
versions in version.php
- $plugin->supported[37,39];
supported takes an array of ascending numbers, that correspond to a
range of branch numbers of supported versions, inclusive. Moodle
versions that are outside of this range will produce a message
notifying at install time, but will allow for installation.
- $plugin->incompatible = 36;
incompatible takes a single int corresponding to the first incompatible
branch. Any Moodle versions including and below this will be prevented
from installing the plugin, and a message will be given when
attempting installation.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
