Note that, instead of going one by one to them from the XMLDB Editor
(load, makes some tiny change, save, revert the change, save), the
report includes a commented line that, once uncommented, does regenerate
the file while reporting.
I've left it there as a commodity for the developer.
It's been a mistake to make every Moodle site out there to check for
available update every two hours, on the hour. We are experiencing
server load peaks that are harder and harder to deal with.
The patch addresses this by (1) checking for available updates just once
a day and (2) distributing the checking times randomly around the clock.
Amended because, in all cases, install.xml wins and we
have make upgrade.php to match it...
But in the question_versions->status case, that needs to
be NOT_NULL, so upgrade was correct and install.xml has
been changed for it.
Note this has been changed without using the editor because
it has been detected that there are other changes in the xml
file that have been added manually, we'll create a "reconcile"
issue to fix that (mainly whitespace).
So, yes, please, always use the editor.
The versioning changes will require some major changes
in the backup and restore of question bank and its
elements. This change introduces those changes to make
it compatible with the new world of versioning in question
bank. This commit also removes quiz_slots fields and
quiz_slot_tags table.
This commit will also introduce the versioning db
structure and some major changes to the quiz
and quiz attempts for the question, random
question and the view.
This commit implements the behat changes for versioning
in core question and associated locations.
This commit adds the changes in questiontype base
to work with new question tables and the new structure in the
databse. Also needed for versioning.
This implementation will also introduct the question status
which allows a question to be in draft and ready status.
I also introduces changes to the base view where it shows
the latest version of the questions. The view of versions
for a question is not implemented in this commit.
This implementation will also introduce changes in the core
qtype plugins to support versioning and the changed
db schema.
This commit implements the new database structure for
versioning in question. It also does the migration of
current data to the new structure.
Co-Authored-By: Safat Shahin <safatshahin@catalyst-au.net>
Co-Authored-By: Guillermo Gomez Arias <guillermogomez@catalyst-au.net>
This commit moves the presets subsystem to a location within the admin
folder, which is more appropriate given its purpose and reduces
developer frustration with tab completion of the admin directory.
Previously, the timeline block courses view included all courses in
alphabetical order, whether they contained any events matching the
relevant filters or not. This could be tedious and misleading if there
were many courses with no events appearing before a course which did
have matching events. Now, courses are only included if they contain
events matching the currently set time filter and search term. When
those values are modified, the block will be refreshed and fetch
results for the current values, and also takes these into
consideration when determining whether to display the show more courses
button.
The sensiblesettings setting has been moved from tool_admin_presets
to adminpresets component where it belongs, in order for being able
to use it from the API to decide whether sensible settings should
be included when exporting them.
The $CFG->grade_navmethod setting has been removed because it is not
required anymore. This setting was used to set the type of navigation
(tabs or dropdown box) which will be used in gradebook. However, these
navigation methods are no longer used and replaced with tertiary
navigation.
Aggregation types can disable column sorting, e.g. both the current
group concatenation types. If such a type is selected for a column
we should update the report sorting options, ensuring that only those
columns that can be sorted are available for selection.
This option allows report creators to avoid duplicate data being
displayed in their report. It is applied only when no columns in the
report currently have aggregation methods applied.
Add new tab to editor, allowing user to select from available audience
types in order to grant access to their reports.
Co-authored-by: David Matamoros <davidmc@moodle.com>
Create the base audience class, to be extended by all audience types
across the site. Implement types allowing audiences to be created per
user, cohort or system role assignment.
The helper class is used for interrogating report audience instances
and retrieving access lists of those users able to view specific
reports.
Co-authored-by: Paul Holden <paulh@moodle.com>
