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.
instance is has been used instead of cmid. This works as all id's are 1
in most cases, but not always.
accesslib_clear_all_caches_for_unit_testing was updated to clear the
$USER->access cache which would fail test when the wrong user's data was used.
Commit for MDL-29663 that renames the FORUM_TRACKING_ON constant
to FORUM_TRACKING_FORCED to allow easier and more consistant reading.
FORUM_TRACKING_ON retained but marked depreciated.
Converts the use of Read Tracking On to Forced. Adds new admin setting
forum_allowforcedreadtracking. If set, Forced will be available when
adding or editing forums. In this state the forced forum overrides the
user preference of off.
With forum_allowforcedreadtracking not set (default) behavior is the
same as now, except forums previously set in the On state are treated
as Optional.
The side effect of forum_allowforcedreadtracking being on, is that users
cannot speed up the loading of course pages with lots of forums by
setting their personal forum read tracking option to off.
Andrew Nicols