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
The `isset` call always returned true for the 'replace' option,
because even if not specified it receives a non-null value. The
`strpos` call now does a strict equality check rather than
greater-than-or-equal (which always returns true).
Note that there wasn't any case of multiple testcase classes in
1 file. All the cases reported in the issue were false positives
caused but other "mock/fixture" files being named _test.
So all this issue does is:
1) rename any _test suffixed class in test files, because we are
going to start renaming a lot of test classes to _test.
2) ensure that the 2 test case classes modified in this issue,
are already observing the filename = classname rule that will
be implemented soon (and verigy it works).
By not redirecting when we are already on the purge caches page we
can preserve the submitted form data, allowing users to easily
repeat the previous action.
In MDL-70689, Eloy and Helen suggested some fixes to improve this patch.
As this is a followup issue to move the pending services, this
very first commit will fix pending things raised in the parent issue.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
The patch adds ability to filter the list of token by the token value,
the user and the service. Also the button to create a new token is made
more prominent and easier to spot.
No need to have a dedicated admin_setting_managewebservicetokens admin
setting subclass, and yet do not use almost any of its features. So the
patch merges the list and the forms handling into a single external
page.
Similarly, it feels like overkill to have a renderer method for a
simple confirmation widget - especially given that the URLs were
hard-coded in it. So that one was dropped.
The patch improves the display of the missing capabilities on the Manage
tokens page and the Select authorised users page. The list of
capabilities is rendered in a collapsible area and does not occupy too
much space by default.
Additionally on the later page, the patch improves the display of the
list of existing authorised users so that it respects the configured
identity fields.
I suppose the original reasoning was that the web services protocols are
pluggable and that plugins can provide external function. But those are
not good reasons to put the whole Web services section under plugins.
Web services are not a plugin type and they always felt very
counter-intuitive there.
From the server administrtaion perspective, web services are similar to
scheduled tasks and therefore, they should live in the same section.
