After some time discussing with integrators, we decided that this
slightly yukky solution probably fits safely, so just making its usage
better explained and speciifc.
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.
This adds the following changes when viewing a list of discussions and
forum_enabletimedposts is turned on.
* Discussions a student wouldnt see right now are dimmed (timestart in
future or timeend in the past).
* A icon appears next to the discussion subject, the tooltip for this
icon displays the display start and/or end time. This only appears for
the user that made the discussion or has permission to
viewhiddentimedposts.
These two changes achieve a couple of important things, namely, teachers
will not mistakenly think their students can see a discussion when
viewing the list if they've later forgot that they set a time limit on
it (or indeed if someone else put it on their discussion without them
realising). Additionally it makes it easy to see from the list when
different discussions are set to be released without having to go in and
edit them to find out.
Change-Id: Ia1818b33c00adae0dad72df8e170a078fb66cd76
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.
The SQL being generated from the selected forum types on the course reset
form was using AND, resulting in never matching anything if more than one
forum type was selected for resetting (as each forum can only have one
type). This should use $DB->get_in_or_equal() to generate sensible SQL.
I removed the last qanda checks in forum_user_can_see_discussion because they are not necessary and
they make the external function fail.
A user in a qanda forum can always see a discussion (he needs to see the discussion to be able to reply).
What he cannot see are the other user posts unless he has replied to the discussion once and the edition period
(usually 30 minutes) has ended.
Note also that forum_user_can_see_discussion was originally only used when displaying forums in blog format
in order to display the button show more or not, this is the reason this wasn't detected before.
Andrew Nicols