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.
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.
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.
The new parameter of curl_security_helper::url_is_blocked() introduced
in MDL-71916 became part of the API. Even if we reverted it quickly,
someone can use a released Moodle version that has that parameter in
place. For that reason and also to avoid potential troubles in the
future (e.g. when yet another argument would be added to this method),
we need to make it clear that the second parameter of this method should
never be used again.
Poor $maxredirects, you did not live long with us. Oh well.
This reverts the original fix introduced in MDL-71916. It introduced an
extra native cURL call inside curl_security_helper to check if the given
URL triggers a redirect to a blocked URL or not.
Shortly after the release, a couple of regressions were reported as a
result of the integrated solution. It was agreed to revert the fix and
progress with implementing an alternative approach.
- This tool is only available for admins
- Before using this tool the hosting admin will need to have NPM installed and be able to run grunt
- To create the docs pages for the library run "grunt componentlibrary"
- After the pages are created the Library is available in Site adminstration > Development > UI Component Library
Add option to class csv_export_writer to prefix CSV file with UTF-8 byte
order mark (BOM). This helps Microsoft Excel detect the file's character
encoding.
When defining settings that are used by scheduled tasks,
it is also useful, or even needed, to know the status
of that scheduled task to have the whole big picture of
that part of the system.
Based on the admin_setting_description, this new setting
reports its name, its status, a link to the configuration.
When adding a new setting of this type, the user can add
an extra description field to complete the whole meaning.
This isn't really a deprecations where something is replaced
by another and all uses must adapt to. Instead it's just a
fallback functionality that will stop working in Moodle 4.2.
Because of that, I've tried to add TODO/@todo comments to
the places that will need to modified, always pointing to
MDL-71421 that is where the removal will happen.
Also, haven't added any debugging() output, after thinking
a lot about it, because this isn't anything that developers
can be using but a internal implementation detail (a fallback)
that we want to remove in some versions.
Provide page for the reports in the course administration.
The page has a drop down to navigate to different reports.
The navigation is remembered just like the grade reports in
the course.
Signed-off-by: Sujith Haridasan <sujith@moodle.com>
The machinery to fix orphaned calendar events that were broken by MDL-67494.
The solution consists of:
1) Upgrade step that checks if this site has executed the problematic upgrade steps and
if positive, it will schedule a new run for calendar_fix_orphaned_events adhoc task.
2) Adhoc task that will self-spawn calling the recovery machinery, running until
all the orphaned calendar events are fixed. It also sets the maximum runtime of
60 seconds. It is also possible to override that number by specifing the desired
number setting the ->calendareventsmaxseconds in your config.php
3) CLI script that will look for all the calendar events which userids
where broken by a wrong upgrade step, affecting to Moodle 3.9.5
and up.
It performs checks to both:
a) Detect if the site was affected (ran the wrong upgrade step).
b) Look for orphaned calendar events, categorising them as:
- standard: site / category / course / group / user events
- subscription: events created via subscriptions.
- action: normal action events, created to show common important dates.
- override: user and group override events, particular, that some activities support.
- custom: other events, not being any of the above, common or particular.
By specifying it (--fix) try to recover as many broken events (missing userid) as
possible. Standard, subscription, action, override events in core are fully supported but
override or custom events should be fixed by each plugin as far as there isn't any standard
API (plugin-wise) to launch a rebuild of the calendar events.
4) Unit tests and helper functions to generate calendar events. We have decided to
keep the tests simple, testing only true and false and not using data generators because
the code is purely to recover the calendar events and won't turn into an API or something
and also due to the urgency of this issue.
The helpers have been created in calendar/tests/helpers.php since there are no data generators
for calendar.
Create a new profile field type, move all existing content of the fields
'icq', 'skype', 'aim', 'yahoo', 'msn' and 'url' in the mdl_user table to
theses new profile fields if needed.
AMOS BEGIN
MOV [aimid,core],[aimid,courseimage,profilefield_social]
MOV [yahooid,core],[yahooid,profilefield_social]
MOV [skypeid,core],[skypeid,profilefield_social]
MOV [icqnumber,core],[icqnumber,profilefield_social]
MOV [msnid,core],[msnid,profilefield_social]
MOV [webpage,core],[webpage,profilefield_social]
AMOS END
