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
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)
This addresses an edge scenario on NFS filesystems with no space
remaining, where subsequent uploads fail silently while zero byte files
are saved to the pool (and for some reason the filesize check passes).
I noticed during the file system abstraction that this test was
incorrect.
Since both $storagefalse, and $storagetrue are in the same context,
component, area, itemid, and folder, the fact that they had the same
filename meant that they constantly overwrote one another.
As part of archive_to_storage, existing files in the same location are
found, the files themselves deleted, and the existing file record in the
files table is deleted.
The tests continued to pass because:
* the existing variables were not affected by the deletion of the file
record and file so the comparisons were successful; and
* subsequent calls to fetch the content of the file meant that the
files themselves were restored from the trash directory.
This change moves all operations which deal with the fetching/updating, or
setting of files from the file_storage class into a new file_system class.
A new file_system can be specified in the config.php and used to replace
all relevant methods in order to move the file system component to an
alternative solution.
Fixes bug where the resource module loads metadata for all files while
building course modinfo, even though it only needs the first file.
(This causes problems if you have ~10k files.)
Changed the course libs such that module and section deletion is now
handed off to relevant functions in the util class and exempted
modules scheduled for deletion from the course backups.
In some cases we may inspect an empty zip file. If we do open
an empty zip file, check that it changed before we attempt to write
it to disk. It may be the case that we were reading the file from
a location that we don't have write access to.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
This lets us convert between common office formats. E.g. docx -> pdf
html -> pdf, html -> ods.
This commit also updates assignment editpdf plugin to use this converter
on all compatible submission files.
With PHP bug #70322 fixed, ZipArchive::close() did start returning false
and throwing PHP Warnings with recent PHP versions (5.6.14 and up).
Previously (5.6.13 verified) it was returning true, and false in older
versions (5.4.x verified).
This change does silent the 2 "hacky" calls to close() that we perform
in core leaving the 3rd one (used for files having files) unmodified.
A new unit test has been created to cover the close() behavior, ideally
supporting both old and new PHP versions without harcoding any PHP
version.
Note that we don't use to rely much on results coming from close(), and
that's a good thing given the buggy behavior commented above. This just
keeps empty zips working like they were before.
