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.
* *_get_completion_state() callback functions have been deprecated and
should no longer be used. Plugins that define custom completion rules
must implement the mod_[modname]\completion\custom_completion class that
extends the \core_completion\activity_custom_completion base class.
- some engine error messages changed
- some warning levels changed
- the carriage return symbol randomly appears
- one phpunit assertion fails and not really representative of anything
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
- Some small namespace/use/MOODLE_INTERNAL/requires reorganization.
- Move file phpdocs to class phpdocs.
- Move external method names to be new "execute" default ones.
- Move unit tests to matching core_grades\external namespace.
- Add missing clean_returnvalue() calls.
This adds a new webservice that creates gradecategories as a batch,
and deprecates the old single creation call, which is superseded.
It also patches a few small issues in the single WS, for any integrations
currently relying on that webservice.
Some recent tests do set a date time element
to ##now## or tomorrow and, immediately after that
the look if, effectively, ##now## and #tomorrow#
have been set (with minutes resolution).
Problem is that, between the field is set and the field
is verified, it can happen that the time advances to
next minute (from H:M:59 to H:M+1:00) and then the
assertion fails.
To avoid this, we could have lowered the resolution to be
hours... but that doesn't solve the problem just makes it
to happen less often.
So, instead of that... we are setting the 2 now and tomorrow
cases to be "today noon" and "tomorrow noon" (12:00:00) so
we ensure they won't be ever in the risk of jumping of minute.
* The activity information output component is still being displayed
even in the case when the activity does not have dates to show and
completion tracking is not enabled.
This also causes a horizontal line to be rendered in activity view pages
below the activity heading which does not serve much purpose when
there's no activity information to be shown.
The activity information output component should only be displayed
if there's completion information to show or if there are activty dates
to show. Otherwise, there's no need to render it.
If a H5P content-type is disabled:
- The content bank won't display existing contents having it as a
main library.
- The content bank won't allow to create new contents using it.
Augument all installed plugin's security helper if there is any.
Plugins function has to be defined as plugintype_pluginname_security_helper in pluginname/lib.php file.
Ref: https://php.watch/versions/8.0/final-private-function#final-private
This applies #712 from upstream libraries.
Unrelated: I've also changed a occurrence of "private final"
by the correct (PSR-12) "final private" in the constructor
(the final&private combination is allowed in constructors)
in lib/classes/event/base.php, because it's the unique case
in core and phpcs was really insisting.
