Instead of fetching the DB record AND then fetching it again (as
part of the vault->get_from_id() call, just use the legacy data
mapper and remove the DB call.
* Remove striped table row style
* Move subscribe icon to the action menu
* Update the action menu icon
* Remove the Last post column
* Removed the "Created" column and moved the date under "Started by"
* Added "Locked" and "Subscribed" indicators under discussion names.
* Added group name with the group picture. For groups without pictures,
a default placeholder picture is now shown.
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.
When grades are deleted, it needs to know the context so any files
in the gradebook can be deleted. This means module delete_instance
functions must delete the grade_item before they delete the module record.
When a user user selects the unread messages link from the forum
discussion page, the link does not include '#unread' in the url.
This patch appends '#unread' to the url by changing the appropriate
value in the reference link assigned to $out within the function
forum_cm_info_view() of the 'lib.php'file.
A similar change is on the forum index.
Grades that have been hidden will appear in the outline/complete
report - even if the user is a student.
The modules that have been fixed are:
* mod_assign
* mod_data
* mod_forum
* mod_glossary
* mod_lesson
* mod_scorm
* mod_workshop
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.
If the user has the following capabilty: mod/forum:canposttomygroups then show them
the more technical of the strings. Otherwise we use something a bit easier for them to ask their
tutor or teacher about.
This checks the courses' current visibility and the users permissions.
If they have the permission to view the course when it is hidden they'll get messages.
We already have checks for the users enrolled & subscription status.
Previously this used the length of the message stored in the database,
before scripts etc are cleaned to display the content. That resulted
in cases where the count would seem much larger than the message size.
The capabilities changed ('contextlevel' => CONTEXT_COURSE changed to
'contextlevel' => CONTEXT_MODULE) are:
* moodle/site:accessallgroups
* moodle/site:viewfullnames
* moodle/site:trustcontent
* moodle/site:viewuseridentity
This list came from reviewing the _get_extra_capabilities functions in
all core activities. They were all somewhat inconsistent, but I think it
makes sense that these capabilities are consistently overridable in all
activities. E.g. moodle/site:accessallgroups affects conditional
availability even if there is no other user of groups, and
moodle/site:viewuseridentity and moodle/site:viewfullnames affect the
logs report, if nothing else.
As a result of this, several _get_extra_capabilities functions are no
longer needed, and all the rest have been simplified.