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.
This feature adds an admin tool for creating custom licenses.
Now custom licenses can be added and amended in Moodle, and the site
default can be set to a custom license.
Core licenses remain hard-coded and are uneditable, so they will always
require update within Moodle core updates, and maintain their
internationalisation through core language strings.
This also includes fundamental changes to the license API including
the addition of license caching and deprecation of no longer required
admin settings for license management.
This function was used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
it internal. Deletion has been documented in corresponding
upgrade.txt files.
The upgrade_fix_block_instance_configuration() function was used
only by deleted upgrade steps so it's safe to proceed with straight
deletion, considering it internal. Deletion has been documented in
corresponding upgrade.txt files.
Site indicators shared with the registration hub used to have the hub
URL in the relevant setting names - such as site_name_httpsmoodlenet.
This upgrade step converts all such settings and drops the URL suffix
because we do not support alternative hubs any more.
Additionally the upgrade step renames the official hub and updates its
URL so that existing registrations with https://moodle.net are still
valid.
All these functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_mimetypes()
- upgrade_fix_missing_root_folders_draft()
- upgrade_minmaxgrade() and upgrade_minmaxgradestepignored setting
- upgrade_course_tags()
- atto_equation_update_librarygroup4_setting()
- mod_lti_upgrade_custom_separator()
These have been kept because continue being used by restore:
- upgrade_group_members_only()
- upgrade_extra_credit_weightoverride()
- upgrade_calculated_grade_items()
This commits removes stuff from different upgradelib files, used
exclusively by the already deleted upgrade steps. Given such
exclusivity it was not needed to proceed with a 2-phase deprecation
as far as the functions were 100% internal to upgrade.
This is the list of deleted functions, all them docummented in their
corresponding upgrade.txt files:
- repository_picasa_admin_upgrade_notification();
- repository_googledocs_admin_upgrade_notification();
- repository_boxnet_admin_upgrade_notification();
- repository_alfresco_admin_security_key_notice();
- qtype_essay_convert_to_html();
- portfolio_picasa_admin_upgrade_notification();
- portfolio_googledocs_admin_upgrade_notification();
- portfolio_boxnet_admin_upgrade_notification();
- mod_book_migrate_moddata_dir_to_legacy();
- mod_book_migrate_all_areas();
- mod_book_migrate_area();
- mod_assignment_pending_upgrades_notification();
- upgrade_mysql_fix_unsigned_and_lob_columns();
- upgrade_course_completion_remove_duplicates();
- upgrade_save_orphaned_questions();
- upgrade_rename_old_backup_files_using_shortname();
- upgrade_mssql_nvarcharmax();
- upgrade_mssql_varbinarymax();
- upgrade_fix_missing_root_folders();
- upgrade_course_modules_sequences();
- upgrade_grade_item_fix_sortorder();
- upgrade_availability_item();
Moodle installations that updated before the 2.8 grade push
were being flagged for a gradebook freeze. This was resulting in
calculated grades being shown as different to how they were
displayed before the upgrade. This fix retains the original
grade value.
When we adjust the weights in natural grading (setup screen), the extra credit items
should not depend on other overrides. If extra credit item's weight was overriden, it stays as it is.
Otherwise it is calculated as itemgrademax / totalgrademax (total excludes extra credit items)
* Upgrades existing data so that the groupmembersonly option is
replaced with equivalent data for the new availability API.
* Removes the database field and admin setting used for
groupmembersonly.
* Changes core modinfo library to remove/deprecate groupmembersonly
data and functions.
* Changes other core library files to remove groupmembersonly
references.
Includes deprecation of several functions, listed in lib/upgrade.txt.
Converts existing data to new structure in database as part of
upgrade, including a progress bar.
Deletes the database tables and fields that were used by the old
system and are no longer needed.
The new messaging default settings can be set in messages.php and deployed
during installation. This also ensures the removing of settings on plugin
uninstallation and contains the update script to populate current default
settings on the existing system when the new feature is introduced.
For security reason we have to avoid using library functions in upgrade
function, so we set defaults the blind way. At this point we do not expect
plugins to have individual messaging defaults presets anyway. The site
defaults are the same as were set for each user using
message_set_default_message_preferences function.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
Simey Lameze