While this is not strictly required, because removal will
happen in PHPUnit 9.0, we are already getting rid of all
uses in core.
From release notes:https://phpunit.de/announcements/phpunit-8.html
The annotations `@expectedException`, `@expectedExceptionCode`,
`@expectedExceptionMessage`, and `@expectedExceptionMessageRegExp`
are now deprecated.
Using these annotations will trigger a deprecation warning
in PHPUnit 8 and in PHPUnit 9 these annotations will be removed.
Also, all uses of expectExceptionMessageRegExp() has been moved
to expectExceptionMessageMatches(). See https://github.com/sebastianbergmann/phpunit/issues/3957
TODO: Various weirdness found while doing the changes with these tests:
- vendor/bin/phpunit lib/tests/exporter_test.php (created MDL-69700)
- vendor/bin/phpunit competency/tests/external_test.php (same issue than prev one)
- vendor/bin/phpunit question/engine/tests/questionengine_test.php (created MDL-69624)
- vendor/bin/phpunit lib/tests/event_test.php (created MDL-69688)
All the setup/teardown/pre/post/conditions template methods
now are required to return void. This was warned with phpunit 7
and now is enforced.
At the same time, fix a few wrong function names,
provider data and param types, return statements...
version = 2021052500 release version
requires= 2021052500 same than version
Why 20210525? (25th May 2021) ?
Because master is going to be Moodle 4.0, to be released
on November 2021. And, until then, we are going to have
a couple of "intermediate" releases:
- Moodle 3.10 to be released 9th November 2020. (2020110900)
This version will be using versions from today to 2020110900
(once it's released the YYYYMMDD part stops advancing).
- Moodle 3.11 to be released 10th May 2021. (2021051000)
This version will be using versions from 3.10 release to 2021051000
(once it's released the YYYYMMDD part stops advancing).
That means that all versions from today to 2021051000 are going
to be used by those 2 "intermediate" releases (3.10 and 3.11).
And we cannot use them in master, because it's forbidden to have
any overlapping of versions between branches (or different upgrade
paths will fail).
So, get that 2021051000, let's add it a couple of weeks to cover
the on-sync period (or a 2 weeks delay max!) and, the first version
that master can "own" in exclusive (without any overlap) is, exactly,
25th May 2021, hence our 20210525.
Significant string changes:
* importgroups_help,core_group - Correcting optional fieldnames
(removing picture, hidepicture and adding groupidnumber, groupingname
and enablemessaging)
* penaltyforeachincorrecttry_help,core_question - additional paragraph
about scoring logic
* resultdownloadready,tool_dataprivacy - wording corrected (no need to
go to a download page)
* auth_dbfielduser,auth_db - varchar data type requirement
Assessment allocation methods normally do not store any personal data.
Their duty is to create assessment records that are then exported by the
workshop core itself.
Still, some allocators (such as the Manual allocation) can store certain
personal data such as user preferences.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
The availability restrictions that apply to user lists (group, grouping)
now apply in workshop:
* In user lists.
* When randomly allocating users (also now works as expected if you use
group mode and a grouping with the activity).
The random allocator's init() method was split into two logical
parts. The init() now handles data from the form and executes the new
execute() method to do the actual job. The execute() method will be
called by the future scheduled allocator, too.
When generating the output of the allocation results, the names of
reviewers and authors are obtained based on the current state of assigned
roles and the 'musthavesubmission' setting. Therefore, when we want to
display information about a re-used allocation, the name of the author
or the name of the author may not be available.
In case of reviewers, we first try to reload the list including the
users without own submission. If it does not help, we just display the
id of the user instead of the name. In case of authors, we just display
the id the user. I can't see much point of eventual fetching the user
record from the database just to populate the list that almost no-one
reads anyway.
There was a bug as these users were ignored only as squares but not as
circles. This patch makes sure that no new allocation are added to
not-grouped users in visible group mode. However, the options 'Remove current
allocations' and 'Add self-assessments' apply to them intentionally.
Also, the user is warned if there are some not-grouped users found in a
workshop in visible groups mode or separate groups mode.
The patch wraps that foreach ($circles as $circleid => $circle)
loop by yet another one for() loop. Reviews are allocated iteratively
now. During the first iteration, we try to make sure that at least one
circle link exists. During the second iteration, we try to allocate two,
etc. Circles are shuffled at the beginning of each iteration.
This is supposed to improve the randomness of the allocation.
The patch also fixes shuffle_assoc() implementation. The previous
implementation actually did not work at all. Also, that removed called
to shuffle_assoc() was redundant here.
Eloy Lafuente (stronk7)