The logic about adding links to view user posts in the forum module
was previously in core code, but there is an existing callback that
means this can be implemented entirely within the forum module.
Co-authored-by: sam marshall <s.marshall@open.ac.uk>
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
* Fetch only the fields required by the function.
* Quick validation of the passed forum parameter. If the forum parameter
is an object, it should have the forum ID and the course ID.
* Default return when there's no need to show a warning yet.
* Return early if the forum's blockafter or blockperiod attributes
are empty.
* If $cm is not passed in forum_check_throttling(), try to fetch it
using get_fast_modinfo() which avoids DB reads. Fetch it via
get_coursemodule_from_instance() as a last resort (though it's unlikely
to happen).
This issue is a followup for changes made in forum. And hence
addresses the following issues spotted for forum:
1. Bring back the "Forums" header in the search page.
2. Remove the stale function forum_update_subscriptions_button
3. Fix the redirection to activity tab when subscription is
changed, in the subscription tab.
Introduces some changes to the exising _extend_settings_navigation()
methods that utilize the global $PAGE object. In order to accomodate
the changes done for the secondary navigation for single activity
courses, the methods that extend the settings navigation can no longer
rely on the $PAGE object, instead the more reliabe way to obtain this
infomation is through the get_page() method from settings_navigation
class.
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.
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
Plus additional amendments to Fred's original commit:
1. Updating the version numbers
2. Merging the original two-step upgrade below into one for simplicity:
1. Deleting the pictures for groups with hidepicture set to 1; and
2. Dropping the hidepicture field itself.
3. Converted array() usages to the short syntax [].
Mihail Geshoski