In PHPUnit 9.1, the following regexp-related assertions
have been deprecated and there are new alternatives for
all them:
- assertRegExp() -> assertMatchesRegularExpression()
- assertNotRegExp() -> assertDoesNotMatchRegularExpression()
This is about to, simply, move all cases to the new alternatives.
Source: https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md
Regexp to find all them:
ag 'assertRegExp|assertNotRegExp' -li
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...
Apart from deprecating forum_print_overview, the following method
has been also deprecated because it's not used anymore:
- forum_filter_user_groups_discussions
This patch adds new capabilities:
'mod/forum:postprivatereply' - whether a user is able to post private replies; and
'mod/forum:readprivatereplies' - whether a user is able to read private replies.
Private replies are only visible to the intended recipient (the author of
the parent post), the author of the private reply, and those with the
ability to read private replies.
If a post is private then it cannot be replied to further.
Note: I have not applied the deprecation policy to these functions as
they are extremely core to the cron functionality and were never
intended to be used outside of cron.
Long history resumed: The test relies on the first group
being the first that is created, the first group is
actually the first one ordering by name. If is
group-999 and is group-1000 is returned
as the first group.
In the recent issue MDL-56225, we started to record the current user as
the usermodified in the forum_discussions table when updating a forum
post. It made sense but it was a mistake.
Even if the current user really modifies the discussion by updating the
post, the field usermodified has actually been always interpreted and
displayed as the last post' author. Not as the last user who touched the
discussion.
This patch reverts that particular change to the previous behaviour and
adds explicit unit test for it.
This patch adds support for time-based locking of discussions.
Discussions are automatically locked after a user-definable period of
inactivity. After this time, only those with the the relevant capability
are able to add replies.
This has been designed to add support for other types of discussion locking
at a later date with relative ease.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
Users that don't have permission to view timed posts outside of the release
time frame will have discussions that have entered the visible frame appear
in an odd order from their point of view on the discussion list.
Example:
Discussion 1, modified 2015-01-01, hidden till 2015-01-03
Discussion 2, modified 2015-01-02, not hidden
The standard 'modified descending' order means that D2 is listed at the top
even after D1 becomes visible. When scanning the list of discussions for new
posts, the user could be tricked into thinking they'd already read it.
This fix instead takes into account the release time of the discussion when
timed forum posts are enabled.
I opted to use CASE statements to handle this instead of GREATEST as the
latter is not supported by MSSQL.
Mainly to verify groups visibility this new callback has been created.
Note this was originally 3 commits but for amending purposes they have
been squashed.
The function forum_get_discussion_neighbours() is used to generate links
to neighbour discussions. I had to change the signature of the function
to have access to the forum's type without the need to re-read it from
the database in additional query.
The SQL query for blogs is a variant of the existing query, just using
the first post's creation time instead of the discussion's timemodified
time.
