All lib_test and locallib_test classes:
- Namespaced with component (and API whenever makes sense).
- Fixed incorrect use statements with leading backslash.
- Changed code to point to global scope when needed or add new uses.
- All them passing individually.
- Complete runs passing too.
Special mention to tests under login/tests:
1) The core_login component doesn't exist.
2) But login/tests are allowed because there is a suite pointing to it (phpunit.xml).
3) So, the only possible namespace for them is "core".
4) And to avoid problems with other core testcases (under lib/tests)
they have been renamed to have login_xxxx as prefix.
Fetching the counts of unread posts should only include unread regular
posts or unread private reply posts directed to the user unless the user
has the capability to read private replies.
In order to retrieve the correct counts, we also need to loop through
each forum instance in the course to check the capability of the user to
read private replies in each forum.
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.
