renamed Visible to Availability and added help strings
AMOS BEGIN
CPY [availability,core_moodle],[modvisible,core_moodle]
CPY [availability,core_moodle],[modvisiblewithstealth,core_moodle]
CPY [availability,core_moodle],[modvisiblehiddensection,core_moodle]
CPY [show,core_moodle],[modshow,core_moodle]
CPY [hide,core_moodle],[modhide,core_moodle]
AMOS END
This introduces a new "controlled link" file type where the file is not
stored in Moodle - but Moodle will control the access permissions on the file.
Plugins can "freeze" a filearea which means Moodle will take ownership of all the remote
files of this type.
When accessing a file, if the "filebrowser" infomation indicates the current user can write to the file, they
will be granted temporary write access.
Part of MDL-58220
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.
We should be detecting when we are treating files that are linked to
external repositories.
For doing that we'd need to return some additional fields via Web
Services:
- isexternalfile
- mimetype (google docs files use an special one)
- repositorytype (the repository plugin name)
We add a new theme config so the theme can say it supports font-awesome.
If this is true, the pix_icon renderer will call a mapping function to map
from the moodle style t/edit to a font-awesome style fa-cog icon name. Then the renderer
will either render an image tag for old icons - or an accessible font-awesome <i> tag.
This mostly works - but there are some places where we don't use the pix icon renderer, and
we directly create image tags with pix_url image sources. These will need updating (Atto icons,
drag and drop move icons, editpdf icons).
The search form options can be achieved in jquery rather than using
global js function/vars.
forum_get_subscribe_link legacylink had not been useful for some time
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.
The 'attachments' is not a real DB field here. It comes from the form's
filepicker and holds the id of the attachments filearea. The function
forum_add_attachment() expects it as a property of the first argument.
There were two possible approaches here. Either to pass the raw $newpost
to forum_add_attachment(), or add the attachments into the list
modifiable fields. The second approach is safer.
